I am running a python script that controls an ADI software named ACE capturing data remotely through port 8080. The ACE will attempt to create an IPC server on the port number. It takes around 12 minutes to capture 1 data set. The script runs normally for capture under 10 minutes. I suspects that the exception occurs because the default ReceiveTimeout is 10 minutes.
I adjusts the ReceiveTimeout in the SMSvcHost.exe.config file but it still not fix the issue. Other threads suggest that I need to adjust the ReceiveTimeout in app.config/ web.config. I am not sure how to locate these file. I am worried I might make changes to the wrong config file. Please advise!
Tracing Information:
[1]: https://i.stack.imgur.com/AKeHA.png
Here is the error message
This request operation sent to net.tcp://localhost:8080/ did not receive a reply within the configured timeout (00:10: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.
Related
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.
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.
In a Silverlight 4 app, I would like to increase the timeout for a specific RIA service load operation (not for all loads, just in a specific case). At Configuring the timeout for a WCF RIA Services call from a Silverlight 3 client I followed a link to instructions that purportedly would allow me to set the timeout.
It appeared to work fine (no compiler error, warning, exception, etc) except that the load operation still timed out early. It appears that with or without the code that modifies the endpoint the load operation is timing out after 2 minutes. There is an Opening event on the ChannelFactory which I subscribed to, and my handler was called at the start of the load operation, so that seems to confirm that the ChannelFactory is being used. Also I set all 4 timeout values (Receive, Open, Close, Send) to 10 minutes just to be sure that I wasn't setting the wrong one.
Why I am unable to actually change the timeout for the RIA load?
I discovered the problem was that multiple timeouts were in play. I was using an EntityFramework domain service for RIA, and I was getting an EntityFramework timeout. I was misinterpreting the source of the timeout as being from the RIA load until I noticed in the stack trace that the timeout was server side. I extended the allotted EntityFramework command timeout to fit my desired load behavior. I was able to confirm that after getting a reference to the channel factory for the domain context I could set the RIA client-side timeout.
NOTE TO SELF: a good way to troubleshoot a timeout is to start by setting it really short to confirm it is working as intended
I have a .NET assembly performing a transformation on a GeneralJournal import file in MS Dynamics AX 2012
Occaisionally I'm getting an error reported relating to a timeout (Looks like a WCF error)
I cannot see in the port setup where to configure any timeout settings.
Anyone know?
The request failed with the following error:
This request operation sent to net.tcp://SERVERNAME/DynamicsAx/Services/GeneralJournalPayroll
did not receive a reply within the configured timeout (00:05: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.
To edit the WCF configuration of a port go to System administration > Setup > Services and Application Integration Framework > Inbound Ports.
Select your port - it has to be deactivated to be able to edit the configuration.
Then click Configure > go to Bindings > set timeout values.
My application has 50 service endpoints (such as /mysite/myService.svc). It's hosted in IIS. Intermittently (once every two or three days) a service stops responding. It's never the same service that hangs. While a service is hung, some of the other services work fine and some other are also hung.
All clients (from different computers) get this error:
ServiceModel.CommunicationException
Message: An error occurred while receiving the HTTP response to
https://server/mysite/myservice1.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.
No exceptions are raised by the server when the client attempts to call the service that is hung. All I have is that error on the client side.
I have to manually recycle the application pool to fix the problem.
Do you know what could be the cause? How can I investigate this issue? I'm willing to take a memory dump of the worker process when a service is hung but I would not know what to search for in the dump.
Update (Aug 13 2009): I have almost ruled out the idea that the server runs out of connections (see comment in Shiraz Bhaiji's answer). I might have a new lead: I log all server-side exceptions in a log file. So in theory, when this occurs on the client, no exceptions are raised on the server; otherwise I'd have proof of that in my logs. But what if an error does occur on the server but is happening at a low level where exceptions are not routed to my exception handling code? I have posted this question about scenarios where low level exceptions cannot be handled. I'll keep you informed of the progress of my investigation.
Sounds like you are running out of connections.
By default WCF has a timeout and therefore holds a connection open for 10 mins.
When you recycle the app pool all connections are closed, and therefore things work again.
To fix it check your code to make sure that you close connections / dispose of proxies.
To resolve this, we set establishSecurityContext to False on the binding.
I have not come across this particular issue but would suggest to turn on tracing/message logging for the WCF service in the config for the service and/or the client app (if you have control over that). I've done this in the last few days for a service that I needed to troubleshoot.
The MSDN link here is a good starting point.
Also see the table in this post for the varying levels of trace detail you can configure. There are several levels which can go from exception only logging to full message details. It is quite quick to set this up in the app.config file.
To parse the log file output use the SvcTraceViewer.exe that comes with the Windows SDK, which if you have it installed should be located in this folder: C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin