In IIS, I have an ASP.net web application that makes many behind-the-scenes calls to an IIS-hosted WCF service.
I never had any issues during development. However, since deploying to a few test servers at work, our tester was reporting that some of the calls were seemingly randomly failing. I verified that indeed, some of those behind the scenes webapp->service calls were failing with a "(417) Expectation Failed". Hitting the back-button and attempting the action again always worked.
A common solution I kept seeing online was https://stackoverflow.com/a/7358457/1669011
After adding that to my web config, the error continued to happen, but instead of returning a 417, would end up returning the results of my web.config's applicationInitialization remapManagedRequestsTo page.
I feel like the web.config fix I mentioned above has just allowed my web application to accept the full body of the response rather than failing when it realised it wasn't the wcf response it was expecting.
So if random services in WCF are returning the results of remapped requests that occur during Application Initialization, does that indicate that my WCF services in IIS are constantly totally shutting down?
What might cause my WCF service to randomly be in a state of "application initialization"? I'm hoping this is just a server issue and nothing to do with my application, as this has come out of nowhere and is risking an upcoming deploy.
Thanks for any assistance
My guess would be time (or very serious exceptions).
Specifically, if the server hosting the WCF service is not being hit often enough, it will shut down the application. Follow the instructions here to ensure the WCF site is not being unloaded: How to keep a WCF site online?.
If it's exceptions, you have not provided enough information to diagnose the issue.
Related
We've been experiencing some deadlocks when working with interconnected ASP.NET WebApis on the same IIS server. We'd like to know if this is somehow an expected behavior, due to hosting all APIs on the same server and same Application Pool, since we have managed to avoid the issue by moving either WebApi to a different pool; or if there's something wrong with our code.
For production, we will probably host the APIs on different server or pools, but still we'd like to understand why this is happening. Our main concern is that, if it's our faulty code, the issue may be reproduced on a larger scale, even if the hosting setup is correct.
We have created a little solution to reproduce the deadlock, hosted in GitHub.
The reproduction steps are as follow:
WebClient executes multiple HTTP request in parallel WebApi1.
WebApi1 executes an HTTP request to WebApi2.
WebApi2 executes an HTTP request to WebApi3.
WebApi3 simply returns a string.
The expected behavior would be that all requests are eventually resolved.
The actual behavior is that, certain requests gets completed, while some others will fail, due to a TaskCancelledException which seems to be due to the requests timing out.
The only article that I was able to find that seems to mention the same issue is from 2014: "Do Not Send ServerXMLHTTP or WinHTTP Requests to the Same Server", I believe that this is the issue we are experiencing, how can we confirm this?
Context
We've been assigned the task to create a centralized authentication server for multiple internal APIs of the company we work at.
We are using IdentityServer3 with reference tokens, so when some API requests a second API using reference tokens, the second API will request the authentication server for token validation which reproduces the issue.
I have added the IdentityServer tag, since this could be a common issue when doing multiple APIs communication and using reference tokens. Sample on GitHub.
Just one observation: you are using HttpClient as a static member for every Controller and according to this HttpClient is not guaranteed to be thread-safe
We've inherited a .asmx web service without source code (my favourite).
We've run tests (calling it from a console app with fiddler attached) both internally and externally and it runs clean every time - as it does for the vast majority of our clients.
However, one user is reporting 5xx type errors. We've tried all the usuals (event viewer and IIS logs) but they're all clean. We can't get it to fail at all.
What further options do we have?
Can the clients replicate the error at will?
The error is most likely data related. Have you tested it with the same data that your client is to produce the error.
The error may also be at the client's end during serialization/deserialization of the call in their auto-generated asmx wrapper.
Has there been a change to the WSDL?
Things like ELMAH are great for logging all unhanded exceptions.
add logging to web config, log everything.
decompile the webservice and find the reason.
This is ASP.NET ASMX Web Service / .NET Framework 4.0.
In web service, I want to execute one method on another thread something like “Fire and Forget” so that Web Service returns some value in response immediately to web site. That method on another thread could take 10 minutes after Web Service returns response immediately to Web site. Also, I do not need return value of that method.
I have tested this scenario using ThreadPool.QueueUserWorkItem and it seems that thread started using ThreadPool will still keep executing even after Web Service returns response back to Web site. Am I correct here? Also is there a better way to achieve this?
The problem is that every now and then, ASP.NET will recycle the app pool. Because it doesn't know about your background task, it will not be considered and will be aborted when the AppDomain is disposed.
Most of the time, the work will complete, but if you run for long enough, you will encounter this scenario.
There are two solutions:
1) The "proper" way is to write a Windows Service that runs outside ASP.NET. You can send instructions to the Service over WCF.
2) The "quick and dirty" way is to write a hidden web service in your ASP.NET site that is never called by users. Your app starts an asynchronous request to the hidden service and then returns its own result to the user, without waiting.
ASP.NET does not know that the request to the hidden service came from inside your app - it just treats it as another request. Because ASP.NET knows about this request, it will not abort it when it recycles.
I have an autocomplete service that executes in under 1ms - perfect! This is a timing of the method.
When I built this service outside of the project, the service call would take a total of 5ms. The service is a ASMX, and returns a JSON result.
But once I integrated this service into the real project it now takes 200ms, although the method call is actually still executing in 1ms. So it must be serialization, ASP.NET pipeline or IIS.
The project is so big it's hard to know exactly what HttpModules/Handlers are running.
So my question is, is there a simple profiler a can place on a HTTP request in IIS that will tell me how long each stage takes?
BTW this all on my local box, before anyone says network speed!
Many Thanks,
Ash.
You can use Failed Request Tracing, but for status code 200:
When calling an asp.net web service from a windows mobile device project, I am catching an exception ( WebException ) and the response inside that seems to be "BadRequest".
This is occurring on a live system but not locally in development. But they both have the same build....
When we point our development code at the live web service we get the BadRequest error again. Is there any way I can get more information about this error?
We use Elmah for logging and can confirm no exceptions are being thrown in the web service itself, in fact, it isn't even getting invoked!
Bad Request is a generic error which means the server didn't even bother looking much at the request from the client because it was significantly malformed in some way (service receive buffer lengths exceeded, etc.).
Try to send the server something simpler from the client until it works and/or gives a different (more precise) error.
Unfortunately, server exception handling or viewing traffic on the wire with a tool like Fiddler is probably not going to be helpful in this scenario.
It would help to know which version of web services this is (ASP.NET 2.0, WCF, etc.).