I have WCF method like so:
public string GetSomething(MyObject obj)
{
return "Something";
}
When I call this from my silverlight app I get an error:
System.Net.WebException: The remote server returned an error: NotFound.....
I call the method from my silverlight app like so:
mProxy.GetSomethingAsync(new MyObject());
Now, when I call the method like this it works fine:
mProxy.GetSomethingAsync(null);
So there seems to be some problem with passing in a complex object.
Note that I return this MyObject from other method and it works fine so it's not a serializable issue. I also changed the maxBufferSize and maxReceivedMessageSize to the max value so it's not that, and i pass in an empty object anyway so it shouldn't be a size issue. And MyObject only contains simple datatypes.
Has anyone any suggestions?
That "Not Found" error is perhaps the single most annoying feature of Silverlight WCF access.
You may want to look into the Service Trace Viewer Tool (here). It's not always helpful (I've run into lots of problems that it wasn't able to help with), but about 10-20% of the time, it'll point me in the right direction.
You may also want to try adding the SilverlightFaultBehavior to your service. It can turn at least some of those "Not Found" error messages into real faults.
I have used the WcfTestClient.exe to debug my WCF services. It gives a much more user friendly error message. If you want to set up Silverlight to receieve WCF faults, I found this page on Data Performance and Fault Strategies in Silverlight 3
to be helpful.
(http://msdn.microsoft.com/en-us/magazine/ee294456.aspx)
Related
I'm trying to add some SOAP message logging capabilities to an old, old ATL Server web service that is running in integrated mode in IIS 7.5 on a Windows Server 2008 box, but running into a strange problem. For further background, I've added the assembly that contains the HttpModule to the modules element of the web.config for the ATL Server web service.
I've been following the answer provided here and the logging itself works great.
However, whenever I use this logging capability, the service responds with "SOAP Invalid Request", while the log file has the SOAP message as expected. I've done lots of fiddling around with it and figured out that this only happens if/when I access the request object's InputStream property in my handler for the BeginRequest event. It will fail if I even simply set a variable to the length of the InputStream like this:
private void OnBegin(object sender, EventArgs e)
{
var request = _application.Request;
//this will blow up
var foo = request.InputStream.Position;
}
If I don't touch the InputStream in my handler (which doesn't do much good when I'm only doing this to log the contents of the request, obviously), the request goes through perfectly.
I can access header values in the Request object and various other properties of the HttpApplication involved, but accessing the InputStream causes the service to choke.
Is there something intrinsic with ATL Server that will prevent me from doing this logging? Do I need to add some sort of locking or other safeguard in my BeginRequest handler to make sure this behaves? Is my handler hosing up the InputStream somehow causing it to be unusable for the service?
Another way of approaching this is to ask if there is a way to see the request as it gets to my service (i.e. after this HttpModule executes)?
It may also be worth noting that I am using SoapUI to test the service.
EDIT:
I've now done some failed request tracing in IIS and I get this error message:
ModuleName IsapiModule
Notification 128
HttpStatus 500
HttpReason Internal Server Error
HttpSubStatus 0
ErrorCode 0
ConfigExceptionInfo
Notification EXECUTE_REQUEST_HANDLER
ErrorCode The operation completed successfully. (0x0)
This comes in the handler for the ATL Server web service (i.e. the DLL for the service). Directly before that is the "GENERAL_READ_ENTITY_START" and "GENERAL_READ_ENTITY_END" messages, and the "END" has this message:
BytesReceived 0
ErrorCode 2147942438
ErrorCode Reached the end of the file. (0x80070026)
Does that mean what I think it means? That the handler isn't getting any data? Is this more evidence pointing towards my HttpModule messing with the Request's InputStream?
Are you sure your request object is valid? You're doing things slightly differently here from the sample you reference. They are extracting the stream from the sender argument whereas you obviously rely on a member variable.
So I finally determined that this wasn't a workable approach: I couldn't get the HttpModule to fire at all in IIS 6 (which I would need to have it to do for it to be an acceptable solution). I tried setting the Filter property on the Request object and all sorts of other crazy ideas, but none that led me to be able to both record the request body in the HttpModule and have the service still work.
So I did more digging and came upon this article on codeproject that talks about the inner workings of ATL Server, specifically the HandleRequest method in atlsoap.h. I mucked around in there for a while and figured out a way to get at the request body in there, and it was pretty simple to write it to a file manually from there.
For those curious, this is the final code I added to HandleRequest():
//****************************************REQUEST LOGGING**********************************************************
BYTE* bytes = pRequestInfo->pServerContext->GetAvailableData();
FILE* pFile;
pFile = fopen("C:\\IISLog\\ATL.txt", "a");
fwrite(bytes, 1, pRequestInfo->pServerContext->GetAvailableBytes(), pFile);
fclose(pFile);
//****************************************REQUEST LOGGING**********************************************************
I am going to still play around with it a bit more, but I have what appears to be a workable solution.
I've been having trouble querying a web server for information from my Windows Phone 7 app, and from my research, I've traced it back to MaxBufferSize/MaxReceivedMessageSize being too low. The problem is, I can't figure out how to change it. Every search result I find talks about the application being a WCF app, and to change the binding in ServiceReferences.ClientConfig. The solution from this post gives this example:
1. edit the ServiceReferences.ClientConfig to accept a large buffer.
<binding name="BasicHttpBinding_MosaicService" maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647">
However, I'm not using a WCF app, and I don't know what the equivalents of the above, and ServiceReferences.ClientConfig are for a regular WP7 application. Can anyone give me some help with this? I've done my best to figure it out myself but I'm getting nowhere.
For reference, in case someone else is having the problem I was (it took a really long time to figure out that this may be the problem), this is what is happening to me: I'm getting a WebException with the message: "The remote server returned an error: NotFound" thrown. And the relevant section of the stacktrace is:
at System.Net.AsyncHelper.BeginOnUI(SendOrPostCallback beginMethod, Object state)
at System.Net.BrowserHttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
I'm not sure how you went from the error message "The remote server returned an error: NotFound" to thinking that your client can't handle the size of the response. Much more likely, the error message is correct and the URL you are requesting can't be found. Drop a breakpoint in your code where you kick off the request. What is the RequestUri property set to on your HttpWebRequest object? Copy that URL into a browser and you'll more than likely see that you get a "page not found". Fix your incorrect URL and all will be well.
I am using the following code in my Global.asax.cs file:
public static readonly IMyCommunicationService GlobalCommunicationChannel =
new ChannelFactory<IMyCommunicationService>("NetTcpBinding_IMyCommunicationService").CreateChannel();
From every website I am accessing the static var "GlobalCommunicationChannel".
That is working very well so far. But sometimes, in production environment, I am getting an CommunicationObjectFaultedException. It says that I can not use my GlobalCommunicationChannel object as the object "System.ServiceModel.Channels.ServiceChannel" is in faulted-state.
I get no more information than that. After some minutes it is working again. Don't know why. I think the connection is re-established or something like that.
What causes this error?
Is there a way to avoid this error in future without adding a try/catch and a retry everywhere?
Thank you very much in advance for your answer!
Check your SessionMode value:
By default, the value of this property
is Allowed, which means that if a
client uses a session-based binding
with a WCF service implementation, the
service establishes and uses the
session provided. (source)
In your service contract, try setting the session to NotAllowed.
[ServiceContract(SessionMode=SessionMode.NotAllowed)]
By default, the maximum number of sessions a service host accepts is 10. So you might check to see if your problem can be replicated in relation to 10 sessions.
I have a WCF client (running on Win7) pointing to a WebSphere service.
All is good from a test harness (a little test fixture outside my web app) but when my calls to the service originate from my web project one of the calls (and only that one) is extremely slow to deserialize (it takes minutes VS seconds) and not just the first time.
I can see from fiddler that the response comes back quickly but then the WCF client hangs on the response itself for more than a minute before the next line of code is hit by the debugger, almost if the client was having trouble deserializing. This happens only if in the response I have a given pdf string (the operation generates a pdf), base64 encoded chunked. If for example the service raises a fault (thus the pdf string is not there) then the response is deserialized immediately.
Again, If I send the exact same envelope through Soap-UI or from outside the web project all is good.
I am at loss - What should I be looking for and is there some config setting that might do the trick?
Any help appreciated!
EDIT:
I coded a stub against the same service contract. Using the exact same basicHttpBinding and returning the exact same pdf string there is no delay registered. I think this rules out the string and the binding as a possible cause. What's left?
Changing transferMode="Buffered" into transferMode="Streamed" on the binding did the trick!
So the payload was apparently being chunked in small bits the size of the buffer.
I thought the same could have been achieved by increasing the buffersize (maxBufferSize="1000000") but I had that in place already and it did not help.
I have had this bite me many times. Check in your WCF client configuration that you are not trying to use the windows web proxy, that step to check on the proxy (even if there is not one configured) will eat up a lot of time during your connection.
If the tips of the other users don't help, you might want to Enable WCF Tracing and open it in the Service Trace Viewer. The information is detailed, but it has enabled me to fix a number of hard-to-identity problems in the past.
More information on WCF Tracing can be found on MSDN.
Two thing you can try:
Adjust the readerQoutas settings for your client. See http://msdn.microsoft.com/en-us/library/ms731325.aspx
Disable "Just My Code" in debugging options. Tools -> Options -> Debugging -> General "Enable Just My Code (Managed only)" and see if you can catch interal WCF exceptions.
//huusom
I had the very same issue... The problem of WCF, IMO, is in the deserialization of the base64 string returned by the service into a byte[] client side.
The easiest to solve this if you may not change your service configuration (Ex.: use a transferMode="Streamed") is to adapt your DataContract/ServiceContract client side. Replace the type "byte[]" with "string" in the Response DataContract.
Next simply decode the returned string yourself with a piece of code such as:
byte[] file = Convert.FromBase64String(pdfBase64String);
To download a PDF of 70KB, it used to required ~6 sec. With the suggested change here above, it takes now < 1 sec.
V.
PS.: Regarding the transfer mode, I did try to only change the client side (transferMode="StreamedResponse") but without improvement...
First things to check:
Is the config the same in the web project and the test project?
When you test from SOAP UI are you doing it from the same server and in the same security context as when the code is running from the web project.
-Is there any spike in the memory when the pdf comes back?
Edit
From your comments the 1 min wait, appears that it is waiting for a timeout. You also mention transactions.
I am wondering if the problem is somewhere else. The call to the WCF service goes OK, but the call is inside a transaction, and there is no complete or dispose on the transaction (I am guessing here), then the transaction / code will hang for 1 min while it waits to timeout.
Edit 2
Next things to check:
Is there any difference in the code is the test and in the web project, on how the service is being called.
Is there any differnce in the framework version, for example is one 3.0 and the other 3.5
Can it be that client side is trying to analyse what type of content is coming from server side? Try to specify mime type of the service response explicitly on the server side, e.g. Response.ContentType = "application/pdf" EDIT: By client side I mean any possible mediator like a firewall or a security suite.
I get a CommunicationException while using WCF service. The message is:
The remote endpoint no longer recognizes this sequence. This is most likely due to an abort on the remote endpoint. The value of wsrm:Identifier is not a known Sequence identifier. The reliable session was faulted.
The exception is thrown in a moment after a contract method was called. Before calling contract method the channel state is Opened. I restore my service client after catching this exception and for some time it works fine. But then this error occures again. It seems like some timeout is exceeded, but I can't understand which one exactly.
I use wsHttpBinding with reliableSession enabled. The InactivityTimeout is set to half an hour and I'm sure it's not exceeded, because exception is thrown earlier.
I solved the problem. The reason was RecieveTimeout on a server side. It was set to 1 minute, so after having no requests during 1 minute server used to close a channel, and when client tried to call a contract, channel was already crashed due to the timeout.
I found the solution after reading this article:
http://msdn.microsoft.com/en-us/library/system.servicemodel.reliablesession.inactivitytimeout.aspx
I received this error while setting up a new WCF service which returned a list of objects.
My understanding is that WCF services can only pass very simple objects back n forth.
So objects with anything other than public properties will not be transferable.
The object had a read only property doing a bit of logic.
Once I got rid of this, rebuilt, and updated the web references, the error went away.
Tip:
If you're returning a object and it has properties check the gets and sets of each one.
We had a problem around it.
I have seen this happen when an application pool gets recycled.
Look at the very last section of this blog about service recycling .