I just created new ASP.NET MVC 4 app, and while inspecting network traffic, I noticed numerous of GET requests.
This is a screenshot of traffic:
http://pokit.org/get/?59050db88c766d3310943b4bbe391de2.jpg
These are request headers http://pokit.org/get/?80e8e84398dfc838938438ec33e5dd92.jpg
So, request occurs every 6 seconds. Could this happen because I installed DevExpress (doesn't make any sense).
Please help, thanks
I guess, this is just an activity related to the browserLink, see http://vswebessentials.com/features/browserlink. This is Visual Studio feature, to sync your css, inspect code and so.
There can be some requests, when in debug mode, because browserLink is doing it's job.
This is very annoying at sometimes.
So there is a documentation about this feature.
And how to disable it - just uncheck it.
Related
We are hosting our website in Azure. During the deployment(TFS) we will do the below Steps as the part of the deployment pipeline.
Stop the WebApp
Deploy Web App Service
Start the WebApp
After the 1st step, if anyone tries to access our website, then by default Azure will return the below page
We really don't want our users to show this page during the outage. We are planning to show our own outage image/page in such case.
Is there is any way to achieve this?
Since Azure Web Apps in a Paas model, I'm wondering how to do this?
Any inputs Appreciated!
It seems that it does not suppport custom error page at this time. There is feedback on Enabling users to create custom error pages for 403 and 503 service unavailable messages.
I think you could up vote to promote the realization of this feature.
Putting some additional information regarding the solution for my own question here,
Just found the OP in SO where the feedback originated
There are two categories of HTTP errors that can happen on Azure Web
Apps:
Those that happen in IIS on the Web Worker where your site is running.
Those that happen before it reaches that. This includes cases when the
site is stopped, in the process of restarting, or potentially affected
by some other issue in the system. One way to tell if an error is #1
or #2 is to turn on http logging, and see if it gets logged. Only #1
will.
For #1, you can customize errors using standard techniques. But for For #2, there is currently no way for you to customize the pages returned by Azure.
Thanks, #David Ebbo and #SamJolly
Recently we have upgraded our main product to be an ASP.NET 4.0 Project (upgraded from 2.0). This project is the main source of traffic to the web service, the other forms have not changed in this release. The web service has been running without issue for a couple years now.
Following the release of the 4.0 environment to our main product our web service starting to die after about an hour and would do nothing but timeout until we restarted the worker process.
We have changed it so that the web service was also in the 4.0 Framework. However this did nothing. Other possible attempts we have tried have also failed such as making it a service instead of a web reference, and updating our certificate validation to also use the proper/current framework techniques.
The worst part is that there is no log in the event viewer being created so I have no leads as to what the problem is. We have applied a band-aid solution of recycling the app pool every 20 min (the recompile takes a second as the web service is very small) and it seems to be holding for now, but we would rather fix the problem than rely on this.
So does anyone have any additional idea/suggestions as to where our problem may be coming from? Or anyone experience anything similar?
Both projects exist in the same web farm and all machines are using IIS 6 32 bit.
Thanks!
edit- Some more info, The web service has a couple basic functions:
1 - accepts XML documents loads them into a dataset then updates internal DBs with the information sent - and simply returns true
2 - receives a request for processed data through XML and queries the DB for it builds XML response and sents it out
3 - receives a confirmation that the data requested in step 2 was recieved and deletes it from the DB
4 - hits a function that updates a DB so we can monitor some applications on our clients systems.
First of all, can you reproduce the problem on a dev box (using some load testing platform to simulate production load)?
If so, then it sounds like an issue with your code. You could then take it a step further and profile the code on the dev server to pinpoint the issue.
If that isn't an option, I would fire up Process Explorer and watch the server resources over time. I'm not sure what your service does, but it sounds like it could be spinning up threads and then not cleaning up after itself.
It might help if you posted some sample code so we could see what could've been affected by the change from .NET 2.0 to 4.0.
Ok, this is one of those really weird errors that seems like the machine's just messing with you.
We have 2 websites, ASP.NET, both were 2.0, and we upgraded them both to 4.0.
They're the same exact codebase, but the web.config files are different, they point at different databases, and they run as separate web apps in IIS.
After the upgrade, one works and one doesn't.
The one that doesn't work will throw a bunch of javascript errors around the Microsoft AJAX Control toolkit like 'Sys is not defined', 'Type is not defined', and '__nonMSDOMBrowser is not defined' (in firebug). When I use the Scripts panel in firebug it lists all the different '...ScriptResource.axd?d=IOBqtxq...' scripts, but when I ask to look at them, many of them will return 'Failed to load source for: /ScriptResource.axd?d=IOBqtxq7p...'.
A couple of them do come back with the CodePlex copyright and some javascript, but many of them don't. And the truly weird thing? If we recycle the app pool for the broken site, we don't get those errors the first time we hit the site. The postback works, we log in, etc. Then we go back and hit it again, javascript errors are back and no postbacks.
Any ideas?
Ok, I hate answering my own questions, but since no one else is weighing in, this is the best we've come up with.
There's a setting in IIS for the website that specifies Web Garden Threads, which I assume is how many threads to use if the site is in a load balanaced web garden. We had this new site set to 7, which is how it was in .NET 2.0. Apparently 2.0 is more forgiving (or ignores it), but 4.0 freaks out. The single request to the site is a request for lots of different resources, which end up being handled by different threads, which as you can imagine makes for chaos. And it's different every time depending on which threads do what.
So, unless anyone else has an explanation for this, I'll close this.
Running many applications out of the same app pool can cause really strange ajax behaviors. Often times you'll see this with apps sharing the DefaultAppPool.
Try creating a separate app pool for the application.
I'm having some problem finding the source of the problem, but here it goes, maybe you know the magic answer.
I'm running this asp.net site with an AJAX updatePanel on my local machine, and everything works just fine, since it's where I developed it. Now, a few days ago, I uploaded the files to my web-host and assigned every single DataBase, and there is no error messages, even though it's still set to debug mode. There is a problem though, whenever I click an element which triggers my asp.net AJAX updatePanel to update, the whole site is updated(which it should not, only the Panel), and my jQuery's (document).ready is called every time as well.
Thank you for any help, I have no idea why this does not work online, nor' do I know why it does work on my local machine.
I have choosen not to upload the code, since I have no idea where the problem might lie, please feel free to ask for the code and I shall reply :)
Have you checked that your web host either:
a) Is running .net 3.5
b) Has the Ajax extensions for .net 2.0 installed
...and that you are testing locally with the same?
If you don't know what the operation aborted error is, here's a Microsoft KB Article about it, http://support.microsoft.com/default.aspx/kb/927917 . There's also tonnes of posts about it but the simple answer for it's occurrence is this; the error only occurs if you try to manipulate a DOM element via JavaScript before the element you are trying to manipulate is loaded.
I know how Internet Explorer's (IE) infamous Operation Aborted occurs and know how to fix it. The problem I have is a very weird scenario. Testing locally and on a development machine with IE7, I never ever get the operation aborted error (both sites running as http).
However on our client's testing site it occurs all the time. Unfortunately my testing environment is not the same as the client's testing environment, so that adds some variables to the mix, but the main difference I see is that the client's testing site is using SSL.
Has anyone ever had the Operation Aborted error only for an SSL site?
The other thought that popped in my head was that it was a latency issue. Locally the site loads up almost instantaneously whereas on my client's testing site, the page loads slower. So with that in mind, I got Fiddler running and simulated the performance to run at old school modem speeds, still no operation aborted error locally or on our own testing server.
FYI: The site is an ASP.NET 2.0 Site using ASP.NET AJAX Extensions 1.0. The page with the issue also has the AJAX Control Toolkit's Cascading Drop Down on it.
And yes as far as I can tell all JavaScript that manipulates the DOM is at the end of the markup, not the beginning.
Any help or comments is greatly appreciated.
Well after scouring the Internet I found the issue. It has to do with a bug in the the ASP.NET AJAX client-side framework.
I'll paraphrase what I found:
The issue is a race condition that occurs due to an Internet Explorer/ASP.Net AJAX bug. The probability of encountering this issue increases when the application has a significant number of ASP.Net AJAX enabled server controls on the web page. The issue is explained here, http://seejoelprogram.wordpress.com/2008/10/03/fixing-sysapplicationinitialize-again . I have added this fix to the project I'm working on.
This fix is still required if using ASP.NET 3.5 SP1.
I guess the reason why you don't have SSL on your test box is due to the cost of the certificate. Did you know you can get Free short term certificates? I've often used them to sort out issues like this.
For example RapidSSL do a free 30 day certificate.