I have a problem running a Java (using Metro) client against a .NET STS and secured web service. However, when I run my .NET based client, it always works.
As you probably already know, when a JAX-WS client is ran, it requests metadata from the service during runtime (even though it already has ran wsimport during design time). However, it seems that this runtime metadata request is where my problem is.
The problem that I'm facing is that during the runtime requests of metadata, some WSDL's exported by my WCF service caused the Java client to just 'hang' during the mex requests. When it hangs, it doesn't even get to the point of issuing the RST request.
For example, I can get to a spot where I have 9 [OperationContract] attributes and it works. But when I add a 10th service method, it doesn't work. However, if I remove one of the 9, then it works. I know there isn't a problem with a particular method because I can mix and match and the same pattern holds.
I can't seem to deduce a pattern or reason for why some WSDL's work and some don't. I strongly doubt there is a limit to the number of service methods. However, could this be a problem with "overall complexity" with the exported WSDL?
Does anyone have any ideas? Have anyone run into this issue before?
If more information is needed, I can glady post it. I'm just trying to keep the initial post a manageable length.
I will also add that I'm running the STS and secured web serivce in .NET 4, and they are based on WIF (so I don't have to worry about security settings). My .NET client is also .NET 4. On the Java side, I'm using Netbeans 6.9.1 with Metro 2.1 running Glassfish 3. I've verified that I receive the same issue running on Metro 2.0.
Please see WSDL Requests with Metro/JAX-WS/WSIT During Runtime for a detailed answer.
Following the example given, there're chances that MaxMessageReceivedSize or MaxStringContentLength limit is reached. Have you tried increasing the values of MaxMessageReceivedSize and MaxStringContentLength for binding? You can try enabling WCF traces, there'd be a warning logged if any such limit is reached.
Related
I have a WCF service to consume in .NET. As per requirement the Action element in the header has to be "http://abc" and the To element has to be "ws://xyz" in order for the service to recognize and respond to the request. The soapAction of the operation is however blank in WSDL and it can't be changed.
My service configuration built programmatically is this:
text message encoding binding with Soap11 envelope version and WSAddressing10 addressing version
no security biding
http transport binding
The setup I found achieving this requirement is "ws://xyz" as the endpoint URL and Request.Headers.Action set to "http://abc" in BeforeSendRequest using a message inspector added using an endpoint behaviour attached to the endpoint. Then I also attach a ClientViaBehavior with the URL of "http://abc".
On my development machine this causes as required
<a:Action>http://abc</a:Action>
<a:To>ws://xyz</a:To>
However on the test server it generates
<a:Action>http://abc</a:Action>
<a:To>http://xyz</a:To>
I don't know exact configuration of the server but I believe it is Windows server as is my development box. Does the same code generates different messages on two different machines or how else would I achieve this? I should also say it worked fine for several weeks and stopped last Monday.
I have found the following later:
The test server has .NET 4.5 on it as well as another machine I tried it on (also failed). The dev machine where it works fine has just .NET 4.0 on it which would suggest it could have something to do with it. However I have no evidence it is caused by .NET 4.5 as it was installed several weeks before the problem appeared. Moreover there have been no Windows updates since it stopped to work!
I've also tried to set the To element in my ClientMessageInspector implementation but the protocol still gets flipped to http.
I think the BeforeSendRequest is not called due miss configration of your service bindings. Check if you have added the the extention configuration to you service endpoints you want to have the behavior.
I have some WCF services which are running great locally; client can consume them and the server is putting data in the DB as expected. The problem is that when I deploy these to a staging machine, all I can see are HTTP 500 errors.
How do I start debugging the problem?
Given that it's only on staging and not on my local dev machine, I assume it's an IIS configuration problem somewhere.
When I use Fiddler to see what's being sent and what the response is, I can see (as expected) correct request data, and only a 500 as the response -- no further details.
I'm pretty green to WCF and IIS, so it's probably something obvious; I've used aspnet_iisreg, deployed my .svc file and all the built DLLs/files from bin; maybe I missed something.
I looked in the IIS logs, but they're pretty skimpy; no error information there, either (or maybe I'm looking in the wrong place?)
(More important than solving the specific problem is figuring out how to see enough details about errors so I can work through problems myself.)
Edit: I of course checked the event logs first -- and surprisingly, didn't find any mention of the exceptions. So I assume that the service is at least being invoked, and that something is faulting in the middle.
The first place to look for errors is event log on the server. There should be basic information why request was not processed. If it is WCF related you can turn on WCF tracing and check for more details in generated logs.
Add:
<httpErrors errorMode="Detailed"/>
In Web.config under:
<system.webServer>
And see what's happening in more details.
'Http 500 Internal Server Error' might occur if your Service Account's password got expired. Please make sure that you don't have any issues with Service Account which is running the app pool on IIS.
It turns out that the server was returning a 500 because of a huge dataset returned; WCF puts some limitations on the size of data (and strings) you can return, to prevent DOS attacks. I solved the problem by increasing the limits, and decreasing the size of data returned (where applicable).
I have a WCF service that has been working flawlessly for 3 months. It is consumed by local clients on the same server hosting the WCF service and local network clients. It uses SSL and basic authentication for security.
A few nights ago, the local client (local network clients not affected) started receiving 404 errors whenever it tried to use the service. I am able to open a browser on the server hosting the WCF and view the WSDL and even call the "put" command and get the expected "method not allowed". I have confirmed that no software or hardware changes have been made to the hosting server. I have confirmed that the SSL key is valid. I have confirmed that the permissions for the Application Pool are sufficient. I have confirmed that no firewall is running. The only thing odd is the IIS log showing that the first post does not contain the basic authentication user. However, the next line in the log does and shows a 200 response. I am not entirely sure that log is not normal. See below. I was hoping somebody could give me another place to research to find the problem. Please let me know.
2010-08-28 10:30:03 192.168.100.100 POST /protected/Service_Name_Here.svc/put - 443 - 192.168.100.100 - 401 2 5 2
2010-08-28 10:30:03 192.168.100.100 POST /protected/Service_Name_Here.svc/put - 443 User_Name_Here 192.168.100.100 - 200 0 0 5
EDIT: The local client that is throwing the error is transferring large files to the WCF service. The local network clients are transferring small files and not throwing the error. I found this link that suggests that the default transferMode="Buffered" will throw a 404 for files above 20 MB file. The fix for this person was to change the transferMode="Streamed". However, the "Streamed" setting only allows 1 parameter to be passed to the WCF service. I have multiple parameters so I need to find a fix for "buffered" mode.
The fix for this person was to change the transferMode="Streamed". However, the "Streamed" setting only allows 1 parameter to be passed to the WCF service. I have multiple parameters so I need to find a fix for "buffered" mode.
Sounds like that's the correct fix, however the caveat is that streamed mode requires custom message contracts; you can't use the "RPC" style that WCF pushes as a default for operations. If you need to provide more than one parameter in a streamed mode transfer, simply add them to your custom message contract.
Here's a nice discussion on the subject from Microsoft.
If you have problems with message size be aware that there are 3 levels of configuring accepted request size for IIS:
WCF - default max message size 65KB (maxReceivedMessageSize)
ASP.NET runtime hosting WCF - default max request size is 4MB (maxRequestLength)
IIS 7 with request filtering installed - default max request size about 28MB (maxAllowedContentLength)
If WCF rejects your message you will probably get meaning full error but for ASP.NET and IIS you will get exactly HTTP 404.
Streaming will not help you unless you change your operations.
I have a silverlight project that calls into a wcf service. Everything works fine on my local machine.
However when I deploy to a virtual machine, with the exact same query the wcf service returns, but the result is empty.
I've tried debugging, but have not been able to get it to break in the wcf service.
Any ideas what the problem could be, or how I could go about debugging it?
Thanks
I figured out what the problem is, but am not sure what the solution is.
In my silverlight project the wcf service I am referencing is http://localhost/.../SilverlightApiService.svc
I used fiddler on my vm to see the request that was made and instead of trying to contact the above service, it was trying to contact:
http:///.../SilverlightApiService.svc
So, for some reason my machine name is getting inserted in there instead of localhost. Any thoughts on this would be appreciated.
I had this exact problem when deploying to amazon ec2 - The machine name for the service was being returned in the wsdl rather than the dns.
There were a couple solutions (one involved creating static wsdl - yuck!)
But the other was creating a sort of factory pattern for the service
This thread (you can read it all, but the answers are at the bottom.)
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/c7fd51a2-773e-41d4-95a0-244e925597fe/
The slight downfall with this is that although it works - if you change the location of the server, you will need to remember to update your config - Which although isn't hard, it's easy to forget to do.
Can you give us a bit more information? What kind of binding are you using? What does the service config and the client config look like? Where do you get your data from that gets returned? Could it be the service on the VM just doesn't get any data? (e.g. queries a database that just doesn't have the data requested?)
Marc
I have had that happen before. I would try this. Set you start page as the web service file and run the app. Then set the start page back to your default page. Then update all the server references in your SL project. Recompile everything and republish. This has helped me a bunch of times in the past.
I figured it out.
Basically my machine name was hard coded in my ServiceReferences.ClientConfig file in my silverlight project.
What I had to do was specify programmatically what url to use for the service reference when instantiating my service client:
System.ServiceModel.EndpointAddress address = new System.ServiceModel.EndpointAddress(new Uri
(Application.Current.Host.Source, "../WebServices/SilverlightService.svc"));
ServiceClient serviceClient = new ServiceClient("BasicHttpBinding_IService", address);
I figured out what the problem is, but am not sure what the solution is.
In my silverlight project the wcf service I am referencing is http://localhost/.../SilverlightService.svc
I used fiddler on my vm to see the request that was made and instead of trying to contact the above service, it was trying to contact:
http:///.../SilverlightService.svc
So, for some reason my machine name is getting inserted in there instead of localhost. Any thoughts on this would be appreciated.
I have a client-server application, in which the client communicates with the server using WCF (WCF is used both in the client and the server).
My problem is, that instantiating the auto-generated proxy in the client, in the following way:
new Service1Client() takes constantly 15.xxx seconds.
I tried to solve this problem, and came to the following results:
1) Compiling and running the same code on other computers, ends up in the same way (always 15.xxx seconds).
2) Instantiating the proxy using ChannelFactory.CreateChannel< IService1 >()
doesn't help (it gives the same result).
My guess, is that whenever the channel factory creates a channel, it tries to do something with a 15 seconds timeout, and when it fails, it continues with creation.
By the way, I use .Net 3.5 without SP1, and cannot upgrade to SP1 :(
Thanks ahead
Even though it is already outdated, it may be useful for somebody else searching for the same. Problem could be with DNS resolution problem, that might be solved in SP1. So you can check if it happens only when you use host name or also with specified IP address.
I've seen this before, where the time was being taken in looking for a proxy server. Check your WinINET (Internet Explorer) proxy settings.
My specific reason for thinking "proxy server" is that it takes 15s. 15s sounds like a nice round number for a network timeout.
Even though this is very old information I just found this issue too although I was experiencing a 7second delay on the First call to a method on the Service Client, I tracked it (in my environment) to Internet Explorer settings as stated above, but in my circumstances it wasn't a Proxy enabled, but the Automatically Detect Settings.
Connections -> Lan Settings and Automatically Detect settings was enabled.
I played with the machine.config and app.config and set
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
Which also made no difference.
I found this answer here and thought I'd contribute a little more information in case someone else in the future experiences something like this.
(This with a .Net 4 WCF service)