I have a peculiar problem with client requests randomly not getting a response to a WCF service call.
The setup is a Silverlight 5 application making calls to a WCF service, using both HTTP and PollingDuplex bindings. The SL makes a number of requests upon loading (20+ in 20s), and every now and then does not receive a response to one or two of them. To be clear, the exact same request works 90% of time, if I refresh the page all requests could get a response.
The error cannot be the actual request sent. I use Fiddler to validate this as well, since I see the request being made (make sure the content is the same as previous successful requests), but there is no response to the request. Eventually the client times out the request. The WCF service is hosted in IIS7, and I have diagnostics and logging enabled on both. In the WCF server trace logs, I only see message logged when the client times the request out. It has the following exception action logged under a "Processing message" activity, at the time of the client timing out:
"The number of bytes available is inconsistent with the HTTP Content-Length header. There may have been a network error or the client may be sending invalid requests."
This is as if the body of the HTTP is not getting through to WCF (I do not know if I can log the full request received by IIS before passing to WCF handlers?). As I said, using Fiddler I can see the full message is valid (note that this behaviour also occurs when Fiddler is not sniffing the traffic, so I've ruled Fiddler out as the problem).
Typically the "Processing message" activity has a "To: Process action xxx"
Like I said this occurs with Http and PollingDuplex services, on my dev box as well as production web servers. Occurs on different endpoints as well, and I don't think it has to do with WCF throttling behaviour, since it occurs
Any information or help will be appreciated to get to the cause, whether it's additional information I can gather to help diagnose or any hints.
Related
We have two applications (client and server) on the same machine that communicate via a WCF service using named pipes.
The issue that we're seeing is that occasionally a request from the client to the server will time out. WCF tracing is enabled on both ends, and on the server side we see the request being processed and responded to immediately as expected. However on the client side we don't see the response and the request times out after 1 minute.
What's suspicious is that almost immediately after the timeout, the client-side WCF trace shows the server's response arriving, almost as if it had been stuck somewhere and the timeout exception caused it to come un-stuck.
Attached are some screenshots from the client trace of the activity that relates to a particular message. Notice that the message gets sent out at 13:26:31.38, it times out at 13:27:31.80, and then the response gets received at 13:27:31.215.
Has anyone ever seen this behavior with WCF named pipes, where messages responses randomly seem to get stuck?
I have implemented message layer security using message inspector mechanism in a wcf service.
On the client side, in IClientMessageInspector.BeforeSendRequest I add an authentication header.
On the service side, in IDispatchMessageInspector.AfterReceiveRequest I inspect the authentication header in the message. If it is not found or as expected, I throw a SecurityException and try to log it to a database.
Here comes the interesting part. When logging to database, I try to read from this webservice again (this is web service which provides configuration info).
This is where the service stalls/deadlocks. I can see that the call to read configuration (when logging to db) is made, but I don't receive the call on the service. I keep getting a timedout exception every time.
After a little googling, I came across this post, which mentions that message inspectors are synchronous in nature. If that is so, how can I achieve what I am after?
We have an attribute called LoggingImplementationBehavior that causes a WCF Logging service to get called before and after service calls it's attached to.
This works great both locally and on the shared development server. However, on the staging server a 401 error is returned when a call is made to the Logging service from the invoker. To ensure that the issue is not in the Logging service I commented all code out so that it does nothing, but I still get this error when the stub is called.
In IIS Manager, Anonymous Authentication is enabled (and nothing else) at both the server level and at the services website level. Digest Authentication is disabled at both levels, so what could be the cause of these 401 errors?
I've seen others have this problem with large data but the data being sent here is quite small.
Any tips on how to continue debugging this problem would be greatly appreciated as I'm currently at a dead end.
The exact text of the error is:
The HTTP request is unauthorized with client authentication scheme 'Anonymous'. The authentication header received from the server was 'Digest qop="auth",algorithm=MD5-sess,nonce="+Upgraded+v171b25f8f2632897bff13b10710dac91aa1d64068a3cccf011b44f8580e932354dfd50d56778ba404d674864cf9d5216e589c616fb1a48583",charset=utf-8,realm="Digest"'.
The remote server returned an error: (401) Unauthorized.
I am have been setting up a WCF Client to connect to a Service that I do not have control of (I think the service is implemented in Java).
The service requires Certificate security and I got all the certificates setup but I get the following error when I connect to the endpoint
An HTTP Content-Type header is required for SOAP messaging and none was found.
I have setup SchemaValidationMessageInspector (http://msdn.microsoft.com/en-us/library/aa717047.aspx) to catch the Request and Response.
I can see that the Request is caught but not the response.
As I understand it is because the response is not of the SOAP format meaning that the Validation method is not triggered.
I expect that the real error is a 404, 403, 500 or something like that.
I have been using Wireshark to inspect the packets but it's all encrypted since it's too early in the "stack". I need the response right after the https decryption have occurred.
How can I catch the none SOAP responses so I can see the error in a clear format?
Use Fiddler or WCF Trace http://blogs.msdn.com/b/madhuponduru/archive/2006/05/18/601458.aspx to see the raw message. If you want to do this from code use a WCF custom messgae encoder http://msdn.microsoft.com/en-us/library/ms751486.aspx.
I'm connecting to a webservice using WCF. I can authenticate on the server correctly, send my request, and get a signed response back.
The only thing is that the body of the response isn't encrypted. Ok, I'm fine with that. It's not my service and not my call how they do things, I'm just writing a client.
The issue is that WCF keeps giving me a MessageSecurityException stating that the'Body' required part of the response message wasn't encrypted. Where in my app.config can I specify that I couldn't give two flying craps that it isn't encrypted and it should be let through and read?
For the record, I'm using customBinding.
The protection level (which defaults to "EncryptAndSign" in WCF) is set on the service contract, e.g. your interface that defines the service methods:
[ServiceContract(Name="YourServiceContract",
Namespace="http://www.yourdomain.com/2009/09/WCF",
ProtectionLevel=ProtectionLevel.None)]
public interface IYourService
{
string SayHello(string inputString);
}
You can set it to "ProtectionLevel.EncryptAndSign" (which is the default), "Sign" or "None".
However, you cannot set it to be one thing for the request and another for the response - the protection level applies to both directions of your WCF communication.
Check out the Fundamentals of WCF Security which explains these topics (this one in particular on page 2).
Marc
There is a way to send a secured message and permit the response to be unsecured. However it requires a hotfix you need to request from Microsoft technical support. This has saved me when workign with a goverment service that required recured requests but send unsecured faults back. See here for more information on the hotfix.