WCF Service Unexpected Exception on Endpoint - wcf

We created WCF services hosted on various windows services. During consumption of the WCF service by another windows service, initially everything goes successfully. But after continuous execution for a day, it suddenly throws the following exception:
The error message is Could not find endpoint element with name 'MemoryClient' and contract 'IQueue.IRepository' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this name could be found in the client element.
The source of the exception System.ServiceModel
The stack trace of the exception:
at System.ServiceModel.Description.ConfigLoader.LoadChannelBehaviors(ServiceEndpoint serviceEndpoint, String configurationName)
at System.ServiceModel.ChannelFactory.InitializeEndpoint(String configurationName, EndpointAddress address)
at System.ServiceModel.ChannelFactory1..ctor(String endpointConfigurationName, EndpointAddress remoteAddress)
at System.ServiceModel.ChannelFactory1..ctor(String endpointConfigurationName)
at EngineChannelFactory.RepositoryClient.CreateNewChannel(String strEndPoint)
THE TARGET SITE OF EXCEPTION -> Void LoadChannelBehaviors(System.ServiceModel.Description.ServiceEndpoint, System.String)
The problem is, it is consuming this same end point for some time. Once the service restarts, the issue is resolved. Has anyone faced this issue? This is happening on Windows 2003 64 Bit Server, where .NET 3.5 is installed. Has someone said if this is an environment issue, and was fixed in .NET 3.5 SP1?
Thank you in advance.

Related

Fault Exceptions Are Not Being Recognized By Calling Service

We are throwing fault exceptions (WCF) in few scenarios. They are working in our local VMs. But when we try them on the server, service is throwing the exception but calling service is not able to recognise them and giving the below error.
The server did not provide a meaningful reply; this might be caused by
a contract mismatch, a premature session shutdown or an internal
server error.
Is there any setting which disables FaultExceptions in WCF services? Any ideas from anybody?
Code added from comment:
[ServiceContract(Namespace = "sample.com")]
public interface ITransactionService
{
[OperationContract]
[FaultContract(typeof(Domain.Exceptions.SimilarTransaction‌​Exception))]
Transaction ProcessTransaction(Context context, Spec specification);
}

WCF + NetTcp: high load make the channel stop working (calls/second rate)

First of all, sorry, i'm not fluent.
I'm trying to figure out why my WCF services stop working when we have an environment with high calls/second rate. I'm not sure that just increasing timeout will solve the issue.
We have 2 webservices:
The first is hosted on IIS 7.5, Windows Server 2008 R2 Enterprise SP1 x64, with AppFabric (and WAS)
Second, hosted on Windows Service, Windows 2003 R2 SP1 x86
Both webservices have minimum configuration: No authentication, No trasaction, Without special treating of message.. check the binding:
<netTcpBinding>
<binding transactionFlow="false">
<security mode="None">
<message clientCredentialType="None" />
<transport clientCredentialType="None"></transport>
</security>
<reliableSession enabled="false"/>
</binding>
</netTcpBinding>
We are trying to use Net.Tcp binding because of its realibility and velocity.
FACT 1 - Net.Tcp Binding is primary reason
When the load is high, the channel Net.Tcp stop working. That's it! But the BasicHttp still working like a charm.
The WindowsService: the channel net.tcp last down for some minutes (3m - 10m) before get working back (BY ITSELF, without we change anything. Goblins are working hard).
The AppFabric/IIS/WAS: the channel net.tcp keep down. Need manual restart.
The BasicHttpBinding configuration is similar to net.tcp: without any treating of the message, whitout security concerns or something like that.
FACT 2 - Without any kind of logging
We couldn't find any kind, tip, trick to figure out what's happening. I have tried Dump the memory, event logs, System.Diagnostics and nothing relevant. The most relevant tip is an Error from SMSvcHost 4.0.0.0:
An error occurred while dispatching a duplicated socket: this handle
is now leaked in the process. ID: 2272 Source:
System.ServiceModel.Activation.TcpWorkerProcess/62875109 Exception:
System.TimeoutException: This request operation sent to
http://schemas.microsoft.com/2005/12/ServiceModel/Addressing/Anonymous
did not receive a reply within the configured timeout (00:01:00). The
time allotted to this operation may have been a portion of a longer
timeout. This may be because the service is still processing the
operation or because the service was unable to send a reply message.
Please consider increasing the operation timeout (by casting the
channel/proxy to IContextChannel and setting the OperationTimeout
property) and ensure that the service is able to connect to the
client.
Server stack trace: at
System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)
at
System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult
result) at
System.ServiceModel.Channels.ServiceChannel.EndCall(String action,
Object[] outs, IAsyncResult result) at
System.ServiceModel.Channels.ServiceChannelProxy.InvokeEndService(IMethodCallMessage
methodCall, ProxyOperationRuntime operation) at
System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage
message)
Exception rethrown at [0]: at
System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)
at
System.ServiceModel.Activation.WorkerProcess.EndDispatchSession(IAsyncResult
result) Process Name: SMSvcHost Process ID: 1532
Do you have any tip or configuration trick to help me solve this issue?
Whats the best configuration for high load scenarios?
If you generated a service reference in Visual Studio, or with the svcutil tool, make sure you always call the Close or Abort methods of your proxies. I encountered a similar problem some days ago because I forgot to call these methods.
In case you are calling the Close() and Abort() methods accordingly and still receive this error consider the following scenario:
You run a Microsoft .NET Framework 3.0-based or .NET Framework 3.5-based Windows Communication Foundation (WCF) service.
The WCF service uses the Net.Tcp Port Sharing Service (Smsvchost.exe) and is hosted on a computer that is running Internet Information Services (IIS).
One of the following conditions is true:
The CPU usage is high on the computer that is running IIS.
A throttle occurs in a service model for the WCF service.
Multiple requests are sent to the WCF service at the same time.
In this scenario, the WCF service takes longer than one minute to process a request from a client application. Additionally, an error message that assembles the following event entry is logged in the event log:
Log Name: System
Source: SMSvcHost 3.0.0.0
Date:
Event ID: 8
Task Category: Sharing Service
Level: Error
Keywords: Classic
User: LOCAL SERVICE
Computer:
Description: An error occurred while dispatching a duplicated socket: this handle is now leaked in the process.
ID: 2620
Source: System.ServiceModel.Activation.TcpWorkerProcess
Exception:
System.TimeoutException: This request operation sent to did not receive a reply within the configured timeout (00:01:00). The time allotted to this operation may have been a portion of a longer timeout. This may be because the service is still processing the operation or because the service was unable to send a reply message. Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.
Note: You must restart IIS to recover the WCF service from this issue.
Cause:
This issue occurs because of the Smsvchost.exe process times out after one minute when it tries to transfer an incoming connection request to the W3wp.exe worker process. Additionally, this time-out is not configurable.
When the CPU has a heavy workload, or when many concurrent connection requests are incoming, the Smsvchost.exe process cannot transfer the incoming connection to the W3wp.exe worker process within one minute. Therefore, the Smsvchost.exe process times out and eventually stops responding. When this issue occurs, the Smsvchost.exe process cannot route later requests to the W3wp.exe worker process until IIS is restarted.
Solution:
Microsoft suggests applying the hot fix 2504602 that is described in Microsoft Knowledge Base (KB) article. This hot fix is available for WCF in the .NET Framework 3.0 SP2, in the .NET Framework 3.5 SP1 and the .NET Framework 4.
In addition, Microsoft claims to have solved this issue in the .Net Framework 4.5, therefore, you should upgrade to the latest version.
In case you upgrade to the .Net Framework 4.5 and the problem persists the workaround is to modify the smsvchost.exe.config file to increase timeout and pending accepts and various other parameters.

How to diagnose ContractFilter mismatch?

I've written up a server in VB.NET that consumes a providers WSDL for functionality and then hosts my own WSDL so that they can communicate with me. In testing it's been working as expect; I can consume my hosted service using SOAP-UI and WCFTestClient effortlessly.
But when our provider attempts to connect to it he received this error:
Yadadada cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher
They're not entirely helpful in resolving this issue and I'm not sure where to start.
After toiling away at this on and off again I realized that the provider, who was trying to access my service, was using an ASMX web service as opposed to the WCF service I had written up. Still having been a little raw to WCF I chose to just redo the work as an ASMX service and thus my problems are solved.
Trials and tribulations of an intern.

Axapta 2009 WCF service

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.

MSMQ backed WCF service hosted in a windows service fails on startup

I have a WCF service hosted in a Windows service that I set to Automatic so it will start automatically when the server is brought up. The service is endpoint is MSMQ backed.
When I start the service manually, everything is good. But when the service starts on bootup, I get a MSMQ exception:
System.TypeInitializationException: The type initializer for
'System.ServiceModel.Channels.Msmq' threw an exception. --->
System.ServiceModel.MsmqException: The version check failed with the error:
'The Message Queuing service is not available (-1072824309, 0xc00e000b)'. The
version of MSMQ cannot be detected All operations that are on the queued channel
will fail. Ensure that MSMQ is installed and is available.
at System.ServiceModel.Channels.MsmqQueue.GetMsmqInformation
(Version& version, Boolean& activeDirectoryEnabled)
at System.ServiceModel.Channels.Msmq..cctor()
--- End of inner exception stack trace ---
It seems like the MSMQ is not ready to be used before the service starts...is there a solution to this?
You need to add a dependency on MSMQ in your WCF service host. You can do this in the service installer:
ServiceInstaller serviceInstaller = new ServiceInstaller();
// Adding this property to your ServiceInstaller forces
// your service to start after MSMQ.
serviceInstaller.ServicesDependedOn = new string[] { "MSMQ" };
If you are not using a service installer, you can also add the MSMQ dependency for your service by editing the Windows registry, as described in "Microsoft Support: How to delay loading of specific services".