I have a WCF service that is coded to throw a Custom FaultException under certain conditions. When hosted locally and on several servers this executes as excpected, Custom fault thrown by service custom fault caught by client, but on production and UAT server the Custom fault is thrown by what the client recieves is a Protocol Exception (500 error).
Is anyone aware of an IIS or sever setting that could be effecting this WCF server? This issue is driving me crazy
I am having a similar Issue,
our server is using a third party web service, when a client connects to our server from the same machine, our server can catch the Fault Exception, but if the client is connecting over the network our server can't handle the Fault Exception, and is only getting the "500 Internal Server Error".
I used a sniffer to see the incoming data, and I can see that the webservice is sending the Fault Exception in both cases, this is a third party webservice so i have no control over it.
the clients use .Net Remotting to connect to the server.
The Solution:
add RemotingConfiguration.CustomErrorsMode = CustomErrorsModes.Off;
to the Remoting server,
for some reason it is affecting the Exceptions it (the server) is receiving.
this is not the ideal solution because now we are exposing our servers Exceptions ...
Related
I built a application with 5 wcf services and hosted them in IIS 7.5. I used the default configuration for the net.Tcp port (808*).
I am not used to host WCF services in IIS (I always hosted in Windows Services) and I found interesting that when I call the service (using tcp binding) I got two different process on the server.
One is SMSvcHost.exe (the one that is actually using the 808 port) and the other is w3wp.exe wich I think is handling a instance of the server I am calling.
I have a lot of questions so I will enumerate them:
Should I use IIS instead of Windows Service to host WCF Services (tcp binding) ?
The fact that I have two processes to answer my request means that I may have cpu impacts ?
Sometimes my services stop answering using the tcp binding. I got a timeout error on my clients but the mex is correctly answering if I go to the http://myServer/Service1.svc. I suspect that this problem is caused by fault connections but I am throwing exceptions correctly (using fault exceptions) and catching them correctly on my clients. Besides, I am also implementing a partial class for every service to dispose corretly (either using Close or Abort methods). Is there any way to figure out what's going on when the services stop answering ?
Shouldn't the w3wp.exe processes be closed after the client ends the request ? They remain on the Task Manager even when no one is using the services. I guess this is the reason of why my Entity Library logging locks the file after my request is completed.
Ideally it would be better hosted in Windows Activation Services (WAS) which is close to what you think of as IIS, but not quite. Here's a good introductory article on MSDN magazine:
http://msdn.microsoft.com/en-us/magazine/cc163357.aspx
This is a problem which has had me baffled for weeks now on a client's Live environment.
The WCF service is hosted on Windows Server 2003, and has both HTTP and MSMQ endpoints.
When placing the service in the test environment, the service cleanly starts and stops, and messages are passed without problems. However on the Live environment, the service starts fine, but does not exit cleanly.
When attempting to stop the service, the machine takes a long time to respond and eventually displays an error saying that the service could not be stopped. Inspecting the error on the event log, it says that it was unable to write to the MSMQ queue (access denied), however, the service is able read and remove messages from the queue. If one then refreshes the service manager, the service is in fact stopped.
The MSMQ queue is hosted on a different physical machine, and we have been unable to reproduce the error on the test environment.
We are not sure if it is related or not, but the service will also occasionally stop pulling messages from the queue. This has been solved by restarting the service. Again, we have not been able to reproduce the error.
Recently we experienced another error with the HTTP based client where upon midnight one night, the service suddenly started rejecting connections with the following exception:
The HTTP request is unauthorized with client authentication scheme 'Anonymous'. The authentication header received from the server was 'Negotiate,NTLM'. ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized.
Even more curious, is that simply restarting the service seems to correct the problem.
If anyone has seen anything like this before or has any comments, it would be much appreciated!
Speaking to a colleague, apparently setting the ServiceModelEx throttling options all to "1" help with the lock ups on MSMQ based WCF services.
I encounter this strange problem while using wcf services along with
L2SQL DAL.
The server is hosted at the localhost and contains an implementation of the correspondent interface. The client is familiar with the interface and occasionally queries the database via the exposed service using tcp transport.
When client runs locally everything's just fine.
But whenever client runs at another machine the 'InvalidOperationException' is thrown in the System.Data.dll (the transport still gets delivered) and over the time the channel enters 'Faulted' state(and transport fails to get delivered).
I feel I'm missing something very basic in my application.
Could anyone please point out possible reasons for such and odd behaviour?
An exception in the service will cause the channel to enter a Faulted state, if you do not clean up properly. See: http://bloggingabout.net/blogs/erwyn/archive/2006/12/09/WCF-Service-Proxy-Helper.aspx
for how to clean up the proxy when the service fails.
On your problem with L2SQL, looks like you allready found a solution.
My service is hosted on IIS7, windows 2008 server with sql server2008 express.
I am getting following error when the process takes more than 2 minutes i got this response, i m unable to find out either it is due to sql server time out or wcf time out. my sql server process is also took long.
An error occurred while receiving the HTTP response to http://REMOTE/SynchronizationService_test/SyncService.svc. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.
I guess the best thing to do is to look through the server logs, as the message suggests.
Learn how to configure WCF tracing: http://msdn.microsoft.com/en-us/library/ms733025.aspx
I have set the mode of service singleton and it works for me.
And also set configuration Throtling of WCF behaviour.
I am trying to add a service reference to axapta 2009. All is working well, its a simple web method(external webservice) that gets executed on the server tier(necessary, otherwise clr interop error)
But I've ran into the following problems :
is it possible to close the proxy one way or another? Because this option is not available in the generated service object in AX (only the webmethods and a tostring).
at a certain moment, i ran into a service with faulted state. Normally, you create the service object again, but this didnt solve anything, until i restarted the AOS. Is this normal behaviour? Is the service object cached or something like that on server side?
Thx in advance.
This is due to the fact that the WCF service is throwing Faults, probably unhandled faults.
Do you have access to the WCF Service? If so then have a look at this link: How do I prevent a WCF service from enter a faulted state?
Try to catch any exceptions within the WCF Service and log them.
Unfortunately Ax cannot catch FaultExceptions thrown by WCF so you will be limited to modify the WCF Service with an object encapsulating the return message, along with a flag if the method processed successfully or if an exception was thrown.
Yes it is normal behavior for a faulted WCF service to stay in the Faulted state. You may have to restart the IIS service or just recycle the AppPooll the WCF Service is running under.