Why is Binding.CloseTimeout value ignored? - wcf

Sessionful client has Binding.CloseTimeout set to 20 seconds:
<netTcpBinding>
<binding name="NetTcpBinding_IService" closeTimeout="00:00:20" ...
a) If service isn't running at the time client calls proxy.Close, then client should wait for 20 seconds ( due to CloseTimeout being set to 20 seconds ) before throwing an exception, but instead exception is thrown almost immediately:
»The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:00:20'.«
Why is CloseTimeout value ignored by client?
thank you

Imagine the client and server are people, and they have a meeting at noon.
The client shows up promptly at noon. If the server isn't there then the client leaves immediately, saying "Screw it!" (throwing an exception).
If the server is there, they commence negotiations (setting up a connection). If the meeting lasts less than CloseTimeout it's because they've come to an agreement (the connection has been set up). If they run out of time for the meeting, they abandon their negotiations (the connection attempt times out).
Lest you think I'm making this up, it's confirmed by the answer to this question over on MSDN:
EncpointNotFoundException [sic] usually occurs if the service cannot be found on the specified address. This exception will be thrown immediately. But if the service is found, yet the sessionful channel cannot be established within 20 seconds, you'll encounter the timeout error.

Related

Diagnosing timeout, connection pool or socket issue

I have a .Net 6 webapplication, that is hosted in IIS on Windows server 2019.
Sometimes after deployment, it will start having issues connection to SQL server and WCF services.
The thing that strikes me is that both types of errors start appearing at the same time. The SQL server, net.tcp WCF services and HTTP WCF services all start throwing these errors at the same time.
This leads me to think it could be some kind of socket exhaustion or similar?
How would I diagnose this kind of broad connection issue?
Note: The application has been ported from .Net Framework to .Net 6, and the old version does not exhibit this behavior, so I suspect that the .Net 6 code has some sort of leak, but I need to find out what is causing it.
Examples of the exceptions:
SQL error after the default 15s timeout:
Begin failed with SQL exception Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.
Another sql error
could not execute batch command.[SQL: SQL not available] Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. The wait operation timed out.
WCF net.tcp service
The socket was aborted because an asynchronous receive from the socket did not complete within the allotted timeout of 10675199.02:48:05.4775807. The time allotted to this operation may have been a portion of a longer timeout. The socket connection has been disposed.
Object name: 'System.ServiceModel.Channels.SocketConnection'.
HTTP HTTP service
The request channel timed out attempting to send after 00:01:00. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. The HTTP request to 'https://www.example.com/service' has exceeded the allotted timeout of 00:01:00. The time allotted to this operation may have been a portion of a longer timeout.

WCF Calls cause "A blocking operation was interrupted by a call to WSACancelBlockingCall" error

In our production environment, we have a WCF serivce that is very frequently called.
We noticed that sometimes, calls to this service (only this one) fail on timeout for a period of time, after everything falls into place and the service responds correctly again.
I used Dynatrace to try to understand what's happening, I noticed that for the calls resulting on a timeout, the method of the service is never called ! And at the same time the server throw this error
A blocking operation was interrupted by a call to
WSACancelBlockingCall
and the client throws a Timeout Exception.
I want to understand the cause of this errors. Is the server error caused by the client's TimeoutException (when the client close its connection) ? Otherwise why do the server throw this error ?
Can you attach a screenshot of that PurePath?
The TimeoutException is simply thrown by the caller of a service when the called web services doesnt return within the default timeout - typically something like 60s. And - once the client aborts its network connection it will cause the exception in the server who has accepted that connection.
There can be multiple reasons for this slow behavior, e.g: you are maxing out the number of connections you have in your client - or the server implementation is overloaded and cant handle incoming requests. Definitely look at the number of worker threads/connections configured on both sides
If you want specific help on dynatrace freel free to send over the PurePaths - check out http://bit.ly/sharepurepath
hope this helps

WCF EndPoint SocketConnction aborted 10 mins after last use

the service endpoint socket connection always abort 10 mins after last use.
the above image shows that the last use of the end point was 10:18:21. after 10 mins, activity Aborted 'System.ServiceModel.Channels.ServiceChannel' happened. is the 10 mins time out a default setting for WCF endpoint socket connection? can I set the timeout to be infinite? notice the abortion happens on a separate thread(thread 16).
or did I not configure the endpoint correct on the service endpoint?
The socket connection timeouts needs to be configured on both client and server side (smaller of the two will prevail). These should be done via binding configuration (in config or code). The timeouts can be done via inactivityTimeout setting of a reliableSession, in combination with recieveTimeout of the netTcpBinding. You can also consider using idleTimeouts in the connection pool settings option of netTcpBinding. It is typically not recommended to set infinite timeouts unless you have very specific needs that need to be met and have service usage parameters that safegaurd against infinite timeouts.

WCF timeout client vs server

Can anyone explain to me what is the difference between the timeout configuration on the server vesus on the client ? For example, what would happen if a client sets the sendTimeout to 5 minutes while the configuration on the server has it set for 1 minute ? Does the client prevail since it initiates the communication ?
Thanks for your help !
I think I got this, take a look at http://omsite.blogspot.com/2008/04/playing-with-wcf-nettcpbinding-timeouts.html.
When client initiates the call to server, the client side sendTimeout and server side receiveTimeout are in effect. The client has to send(or push) all the data before receiveTimeout set on server expires. The server has to complete its operation and return the results back to client before the sendTimeout set on the client expires.
If the roles are reversed, meaning server is opening communication back to client (like in a callback etc), then sendTimeout on server and receiveTimeout on client come into play.
There is also OpenTimeout and CloseTimeout which control the channel connection establishing timeouts and work at lower channel levels (line sockets etc)
In tests the scenario that you asked. The timeout of the request is 5 minutes, which was defined in the client
On the Client-side Timeouts
SendTimeout – used to initialize the OperationTimeout, which governs the whole process of sending a message, including receiving a reply message for a request/reply service operation. This timeout also applies when sending reply messages from a callback contract method.
ReceiveTimeout – is not used
On the Service-side Timeouts
SendTimeout are the same as on the client
ReceiveTimeout – used by the Service Framework Layer to initialize the session-idle timeout which controls how long a session can be idle before timing out.
See https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/configuring-timeout-values-on-a-binding

WCF call fails because underlying connection was closed

I'm making a call to a WCF service but I get a CommunicationException on the client while receiving the response from the service.
System.ServiceModel.CommunicationException: An error occurred while receiving the HTTP response to http://localhost:8080/Service. 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. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
The client that makes the call is a WCF proxy client.
The service method executes without
any exceptions.
The WCF call works fine in those cases where it does not
take a long time for the serivce
method to finish.
The WCF call fails with the above exception message when the service method is taking long time to finish.
The sendTimeout property of the client's binding has been increased to 30 minutes to accommodate the time it can take for the service method to finish.
Try to set the receiveTimeout equal or greater than the time it takes for the service method to complete. The default value for the receiveTimeout property is 10 minutes. So if the service method takes longer time to complete the connection will be closed (if no other activity takes place before the receiveTimeoutoccurs). The receiveTimeout property is described here.
A very long operation like this should most likely be called asynchronously - in other words, the client asks the server to prepare the data, then gets on with something else while the server does the work. When the server's finished it calls the client back.
Asynchronous WCF operations are discussed here.