I use JavaScript to post an Asynchronous Request to a Web Service. This works about 95% of the time. Sometimes, the request fails to be processed.
Below is the error message in the Trace file of IIS:
2009-02-24 06:14:40 W3SVC861612620
10.248.24.20 POST /TestWebService /TestWebService.asmx - 3112 -
10.250.201.45 Mozilla/4.0+ (compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+1.1.4322.2032)
500 0 0 1148 954 124876
This shows that the internal Error 500 has occurred to the request. Is there any way that I can get to know this in the JavaScript where i have posted the request from? Any workarounds are also fine.
Since you don't provide information about your javascript library, this will be hard to troubleshoot. However, if you're running on IIS 7, you can enable Failed Request Tracing.
Troubleshooting the old school way: your web method is generating an error 5% of the time, meaning it works in certain cases but fails in others. This is likely caused by the parameters sent to your web method. Even if you're unable to trap any runtime requests to your webmethod, you can inspect your logic to see what parameter conditions would cause a failure. Better yet, build a battery of unit tests to call your web method, passing every possible combination of parameters that is feasible.
Related
I am using google search console's URL testing tools API for a while, and I am receiving a bunch of 502 bad gateway errors. I had submitted a quota increase request to bump up our default requests per day and described that we needed an increase in requests per minute (default is 60/minute). But unfortunately, google support has not responded yet. We are trying to call this API in parallel.
This is the error :
Request failed with status code 502
Could anyone help me understand this issue? I feel that we are exceeding the quota limits because 502 is usually associated with an issue while communicating with the upstream server.
I have reported the issue in Google's public issue tracker. Please add your feedback there.. https://issuetracker.google.com/issues/194021199
It is broken and only works some times. The worse part is that it reports back as HTTP 200 in the google console without any errors so they probably have no idea that it is even broken.
I am setting up an ASP.NET WebApi application running on the Azure web application environment. Most of my controllers and endpoints work fine, but there are about 10 routes that return 500 errors "An error has occured". It's not random. It's the same routes every time and I can find no pattern (not all the HTTP methods, from different controllers where other routes in that same controller work fine, and so forth)
When these errors occur, no error logging gets triggered as far as I can tell in the app. (I am using Raygun.IO if that matters). I tried adding a global.asax file with following lines in the Application_Error function:
Exception ex = Server.GetLastError();
new RaygunClient().SendInBackground(null, ex);
but as far as I can see, it doesn't get triggered when these 500 errors occur. The only thing I have found in the Azure server logs is the following warning in the Failed Requests log:
However, I don't see any errors in the trace previous to that point. I'm also not finding any other errors in any of my Azure logs that I can relate to these failing routes.
It's .NET 4.6 (tried 4.5.1 and 4.5.2 with no difference) WebApi using an OWIN startup class. Also tried updating all my packages to no effect.
Check to be sure you don't have routes that conflict. When a URI matches two or more controller actions, and thus Web API can't pick one, you will get a 500 error.
If you have a consistent repro, then you can use remote debugging to attach to your web app and debug it (https://azure.microsoft.com/en-us/documentation/articles/web-sites-dotnet-troubleshoot-visual-studio/). If you can repro it through the browser, you can also turn the custom errors page off so that it shows the stack trace through the browser (<customErrors mode="off"/> under <server.web>).
Also, you can enable better diagnostic logs using the web app settings. Information on how to do so is here: https://azure.microsoft.com/en-us/documentation/articles/web-sites-configure/ under the section "Enabling diagnostic logs".
Also, as Brent said, URL conflicts can cause some nasty errors which aren't immediately obvious.
I figured out what was going on. There were actual errors occurring (mostly SQL related), but the way that we had configured the functions and error logging in those functions, the actual errors were being swallowed up and lost, overriding the error logging behavior of Raygun. I went through and ripped out the Try/Catch blocks we were using for error trapping and logging and the real errors finally emerged into the Raygun dashboard.
My application is deployed on IIS 7. I want to check the number of failures as my logic is getting failed at some point and getting errors.Is there any general weblogs in IIS.I can only see system errors in the event logs. Is there any web logs?
Manually trawling the standard W3C logs is ok if you're chasing down requests for certain content types, but they won't tell you an awful lot about why your web application is failing and responding with many 4XX and 5XX status codes. You'll get a status code, but that's about it.
Failed Request Tracing:
Your "go to" diagnostic tool should be the Failed Request Tracing feature that is built into IIS7+.
FRT is one of my favourite features of IIS7/8 for tracking down problems with production sites, especially when debugging apps built on the WebAPI and Ajaxy type stuff.
For more information see:
http://www.iis.net/learn/troubleshoot/using-failed-request-tracing
For example, last week FRT helped me get to the bottom of an issue with a client's hosted site. A particular part of the site (which uses the WebAPI) was failing with a 405 Method Not Allowed status code when making a HTTP DELETE request and despite the DELETE verb being permitted.
Using FRT I was able to generate trace of the failing request which showed me this:
Expanding the "View Trace" entries revealed this error:
The solution for our customer was to disable (it's not used) the WebDAV native module which doesn't permit non-Windows authenticated requests with certain verbs (such as DELETE) to complete. Even if the WebDAV module isn't handling the request it's still in the request pipeline inspecting and validating request headers.
Failed Request Tracing is a really invaluable diagnostic tool, you should learn how to use it.
The HTTPERR Logs:
You should also check the HTTPERR logs located in:
C:\Windows\System32\LogFiles\HTTPERR
If you get 503 - Service Unavailable errors they're a good place to look for clues as to what went wrong if an application pool fails catastrophically, and often.
The is a folder named 'logs' in your 'inetpub' folder where all the logs live. You can look at the Logging tab under IIS in IIS Manager to see the name of the specific log you should check for your site.
When I build server using Node.js. Requests can sometimes fail. For example, there can be error in parsing POST data. When any error happens:
should I continue handling the request and risk that some of those POST data may be corrupt or missing and respond as if nothing happened (or respond and notify the user, that some error happened)?
try to reparse POST data (and if it fails for, let's say, 3 times, stop trying, add error to error log and show error page to user)?
stop the request handling immediately and throw 500 error?
What is the best way?
The key questions to ask yourself in this situation are IMO:
do I know why the error happened;
can I recover from it?
The answers depend solely on your application. Generally, retrying something only makes sense if you can expect a different outcome with the next attempt. This typically applies to various unexpected errors when integrating with external systems. On the other hand, if the error that you get clearly states that it received e.g. a bad request, or that a file does not exist, then this is probably not going to change no matter how many times you retry the same operation.
If your business rules allow you to continue the operation while ignoring the error entirely, then do so. If your business rules allow you to carry out the request partially and you're able to report the partial failure - then do so. If the error prevents any processing of the request whatsoever, then you'll have to terminate it and report back to the user.
It seems to me that you had a particular situation in mind, so let me address request body re-parsing. In a proper system doing this should be utterly pointless - if you expect different outcomes, then there is something fundamentally wrong with your setup because the body of a request should not change once it's received. Your application should never modify request data in any way.
As a more general rule - if you expect that something unexpected might happen in your application, but you have no idea when, why or how, then there is something wrong with how the application is structured / executed. You should own your code and know exactly what it does.
I am on IIS 7 with a Classic ASP application using Server.GetLastError() and i added this script that writes the error details to a database as a custom '500.100' error in IIS to execute this URL. So far it's been working on most situations when there is an error in the application. However, I am noticing in the IIS log that many people are getting ASP_0147 | Internal Server Error with a 500 error and no further explanation.
I am trying to catch this error showing up in the IIS Log using the method explained above, however, these errors are not being caught (written to database) using the application i made, whereas other types of errors are being caught, but the only errors that are being caught using the script/database i made, already show up with the entire error details in the IIS log.
So the question is, how can i catch the errors still happening in the IIS Log in the database using custom errors? because the method i'm using obviously isn't catching all the errors that show in the IIS Log, only the ones with an explanation being displayed in the log. Or, if I change the Error 'Feature Settings' to 'Detailed Errors' (because now its set on, Detailed only for Local Requests) will it show up in the IIS log, etc? Why am i only seeing 500 error in the IIS Log on certain things, but not on others? Thanks.
This could be an application stall.
If the server gets a lot of requests on the same time, causing the server to "get busy", it stalls some of the requests and possibly denying them. This could give a false-positive 500 error with the error-description (0x0).