I have a project that uses .NET Framework 4.0.
It creates the instance of HttpListener that handles long-lasting HTTP requests that may be idle for a long time (30 minutes or longer).
I control both the server and the client.
Seems that HttpListener class has a timeout that causes the HTTP connection to close if there is no data sent for some time interval.
I need to increase that timeout value. What is the way to do it in .NET 4.0?
There is a TimeoutManager property http://msdn.microsoft.com/en-us/library/system.net.httplistener.timeoutmanager.aspx which has the required “IdelConnection” setting, but it only appeared in 4.5
Related
i'm suffering the same issue as
WCF consumer doesn't get response within the timeout limit, although the service itself is done
here, timeouts are set correctly. other application like soapui are getting response back from server on the same client.
also not getting any error, just wait until timeout is reached, this is on a Windows 2019 with IIS 10. Client is a win32 application on Windows 10. When connecting to windows 2008 it is getting the right response
I managed to rebuild the dll's on .net 4.8 but no difference on the response.
Any help ?
I am using Visual Studio 2012 to generate a web service to be used by a winforms client. I created the client side by using "add service reference". This winforms client is a .net c# replacement of an old VB 6 app. Previously, in the VB app there were external settings for timeout values including the following:
DNS timeout
Connect timeout
Request timeout
The DNS timeout would work when the endpoint host address is a FQDN forcing a DNS lookup. The timeout value here would place a limit on the amount of time to wait for DNS resolution.
The connect timeout would place a limit on the amount of time the winforms client would wait to establish an http connection to the server. DNS lookup would have been successful.
The request timeout would place a limit on the amount of time to wait for the request to return after an http connection was successful. This would come into play if a long running query took too long after the web service call was initiated.
Is there something similar to the above in .net 4.0. I would like to be able to configure this in the app.config. I do know about the below.
<bindings>
<basicHttpBinding>
<binding name="IncreasedTimeout"
openTimeout="12:00:00"
receiveTimeout="12:00:00" closeTimeout="12:00:00"
sendTimeout="12:00:00">
</binding>
</basicHttpBinding>
Could these map to the ones I need or does it really not matter?
thanks
The OpenTimeout setting for the WCF binding is for the length of time to wait when opening the channel, so I believe this will be analogous to your old Connect timeout. This should be fast so you normally would only want to specify a few seconds to wait (30 or less), not 12 hours.
The WCF CloseTimeout is for when a Close Channel message is sent, and this is how long to wait for an acknowledgement. This may not have an equivalent in your old architecture. Again, this should be fast and should only need a few seconds.
The WCF SendTimeout (for the client config) essentially covers the time for the Client to send the message to the service, and to receive back the response (if any). This would correspond to your old Request timeout. This may need to be for several minutes if your server takes a while to process things.
The WCF SendTimeout (for the server config) is for when you want callbacks, so that the Server knows how long to wait for acknowledgement that its callback was received.
The WCF ReceiveTimeout does not apply to client-side configuration. For Server-side config the ReceiveTimeout is used by ServiceFramework layer to initialize the session-idle timeout (to be honest I don't really know what that is)
This MSDN discussion may be helpful http://social.msdn.microsoft.com/Forums/vstudio/en-US/84551e45-19a2-4d0d-bcc0-516a4041943d/explaination-of-different-timeout-types?forum=wcf
As a final note, having really big timeout values isn't a good idea unless you definitely have long running requests. This is because you can run out of available resources on your server if the client isn't closing the connections properly.
We observed the following behavior on one of the servers hosting a WCF service on IIS 6.0:
The IIS log shows a high value for time-taken (> 100000)
The HTTP status code is 200
sc-win32-status code shows a value of 64
I found out that sc-win32-status code of 64 indicates "The specified network is no longer available"
Initially I suspected that it could be because of limits set on MinFileBytesPerSecond, which sets the minimum throughput rate that HTTP.sys enforces when sending data from the client to the server, and back from the server to the client.
But the value for sc-bytes and cs-bytes indicate that the amount of data is sent is within the range generally observed for the service.
Also note that the WCF service is hosted on four boxes and is load-balanced, but the problem occurs only one of the servers. (but not essentially on the same server). The problem is also intermittent.
Has anybody else encountered this error? Any clues about what could be wrong?
Update
Note: Observation on IIS 7.5 (IIS version does not really matter)
I was able to replicate the issue. The issue occurs if:
1. The WCF service takes a long time to respond
2. The client proxy times out before it receives a response from the server. In this case it leads to TimeoutException on the client.
3. The server keeps waiting for TCP ACK for the client, which it would never receive.
Hence a long timeout (TCP socket timeout (default value: 4 minutes) and sc-win32-status of 64
So essentially it appears that WCF code is taking a long time to respond and the client is timing out, what I observe in IIS log is just a symptom and not a problem.
The behavior you are describing will also occur if you exceed a WCF service's max sessions, calls or instances (depending on how you have your service instancecontext mode configured). If you observe the System.ServiceModel performance counters for %max concurrent sessions and/or %max concurrent calls (again depending on your service's instance context), you may see a correlation with the IIS log entries.
Note that these maxes can be configured in the service throttling behavior.
https://msdn.microsoft.com/en-us/library/vstudio/system.servicemodel.description.servicethrottlingbehavior(v=vs.100).aspx
I saw your question again and wanted to point out that I found a solution for this. It turned out to be this piece of code in the web.config:
<pages smartNavigation="true">
After turning this off I stopped receiving the same time-out errors. See also the answer here
IIS put the services into sleep to save recources.
Copied from here (WCF REST Service goes to sleep after inactivity)
The application pool hosting your service defines Idle Time-out property (advanced settings of app pool in IIS management console) which defaults to 20 minutes. If no request is received by the app pool within idle timeout the worker processes serving the pool is terminated. After receiving a new request the IIS must start the process again, the process must load application domain and all related assemblies, compile .svc file, run the service host and process the request.The solution can be increasing idle time-out but the meaning of this time-out is correct handling of server resources. If the process is not needed it should be stopped. Another ugly workaround is using some ping process (for example cron job or scheduled task on the server) which will regularly ping call some method on the service or page in the same application.
We have a Silverlight client which runs "out-of-browser" on a Mac. This client consumes a WCF service through a polling duplex binding.
In the client I am listening to the "Faulted" event exposed by the "InnerChannel" property of the System.ServiceModel.DuplexClientBase derivative which represents the service in the client side.
After exactly one minute this "Faulted" event is triggered and after that the channel is not working anymore, i.e. when the server tries to send a message through the callback channel it gets a timeout exception.
Here is a theory I have: I suspect that the underlying polling operation in the client has a timeout of 1 minute. In the server side the serverPollTimeout property of the pollingDuplexHttpBinding section is set to more than one minute. This means that the server holds a poll request for more than one minute if it has nothing to tell to the client during that time. I suspected that this revealed to the timeout in the client poll message. To test my theory, I've reduced the serverPollTimeout setting to less than a minute and indeed – the problem is not shown.
In the client-side, there is the PollingDuplexBindingElement.ClientPollTimeout property which is according to this blog exactly the setting which should tell the client to wait for more than a minute. The default for this setting is 5 minutes and I've even set it explicitly – but the problem still remains (without the workaround as described above).
Please note that this problem happens only on Mac out of browser client.
To sum-up, here are my questions:
How/where can I see a descriptive error message which tells exactly what is the problem here?
Why does it happen only in Mac out of browser client?
Can someone confirm my theory?
If my theory is true – how can I really set the timeout for the polling request in the client?
After a long thread regarding this with Microsoft support here are the conclusions regarding this issue:
The problem is relevant also for "regular" WCF calls. If we call a regular WCF operation from SL Mac OOB, it will timeout after exactly one minute, even-though the timeout is set to be higher
Microsoft confirmed that 60 seconds is the default timeout on Mac OS and that the SL runtime doesn't call the required Mac OS API to set it to higher value even-though the SL client code uses the documented SL API for changing the timeout. They say it’s "by design" since they are not aware of any scenarios where the server might take that long even in a long poll
I've got a WCF client talking to a WCF server (on the same machine). We use netTcpBinding with message-level security (using a custom principalPermissionMode and a custom implementation of serviceCredentials). The service is marked with InstanceContextMode.PerSession.
The WCF service is self-hosted in a Windows service (not in IIS).
In order to fake keep-alive, we have a Ping method that the client calls every 15 seconds. We keep the client proxy open for the lifetime of the client program (because initializing the session is expensive in our case).
Despite this, the connection is dropped after 9 hours, 1 minute and a bit (in 10 test runs, 7 of them died after 9h1m6s).
The only thing of consequence in the WCF logs is a "SocketConnection aborted" message, followed by a varying set of exceptions, but usually including a "connection was in the faulted state" exception.
Is there some timeout in WCF, or in TCP/IP, that's causing this? Because I'm stumped.
After much tedious investigation: After about 9 hours, the WCF client re-authenticates with the service. Something I'm doing during the authentication step is killing the existing session.
From your comments above you were running the tests at the same time.
Were they also on the same server, using the same application pool?
If so a recycling of the application pool could have caused all the tests to stop at the same time.