• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1800
  • Last Modified:

Error with WCF on client after 10 minutes

I am having an issue with WCF in .Net 4.5

My client application throws and error after 10 minutes.  I have researched the web and have extended every timeout I could fine – with no luck.
My console application is designed to run on a local network.  It performs calculations in excel sheets that can take hours to complete – therefore erroring after 10 minutes is not good.

To troubleshoot I have created a test host that uses the Sleep method for 10 minutes, it crashes each time.  I am not sure how useful the content of the error is since it seems to be rather generic.  Before I have my client call the host, I confirm the different timeout settings.  Below is what the client shows:

CloseTimeout Hours: 23
CloseTimeout Minutes: 59
CloseTimeout Seconds: 59
OpenTimeout Hours: 23
OpenTimeout Minutes: 59
OpenTimeout Seconds: 59
ReceiveTimeout Hours: 23
ReceiveTimeout Minutes: 59
ReceiveTimeout Seconds: 59
SendTimeout Hours: 23
SendTimeout Minutes: 59
SendTimeout Seconds: 59

I have included the error from the client below, I am not sure how helpful this is.  Also, the host application does not thrown an error message.  

ERROR: An error occurred while receiving the HTTP response to http://localhost:8
000/DistributorService/DistributorService. This could be due to the service endp
oint binding not using the HTTP protocol. This could also be due to an HTTP requ
est context being aborted by the server (possibly due to the service shutting do
wn). See server logs for more details.

Unhandled Exception: System.ServiceModel.Security.MessageSecurityException: An u
nsecured or incorrectly secured fault was received from the other party. See the
 inner FaultException for the fault code and detail. ---> System.ServiceModel.Fa
ultException: The message could not be processed. This is most likely because th
e action 'http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT/Cancel' is incorre
ct or because the message contains an invalid or expired security context token
or because there is a mismatch between bindings. The security context token woul
d be invalid if the service aborted the channel due to inactivity. To prevent th
e service from aborting idle sessions prematurely increase the Receive timeout o
n the service endpoint's binding.
   --- End of inner exception stack trace ---

Server stack trace:
   at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecurit
ySessionChannel.ProcessRequestContext(RequestContext requestContext, TimeSpan ti
meout, SecurityProtocolCorrelationState correlationState)
   at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecurit
ySessionChannel.ReceiveInternal(TimeSpan timeout, SecurityProtocolCorrelationSta
te correlationState)
   at System.ServiceModel.Security.SecuritySessionClientSettings`1.SecurityReque
stSessionChannel.CloseOutputSession(TimeSpan timeout)
   at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecurit
ySessionChannel.CloseSession(TimeSpan timeout, Boolean& wasAborted)
   at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecurit
ySessionChannel.OnClose(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.OnClose(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Close(TimeSpan timeout)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage req
Msg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgDa
ta, Int32 type)
   at System.ServiceModel.ICommunicationObject.Close(TimeSpan timeout)
   at System.ServiceModel.ClientBase`1.System.ServiceModel.ICommunicationObject.
Close(TimeSpan timeout)
   at System.ServiceModel.ClientBase`1.Close()
   at redactExcelDistributed.Program.Main(String[] args) in d:\_dev\Distributor\
redactExcelDistributed\redactExcelDistributed\redactExcelDistributed.cs:line 219
0
rye004
Asked:
rye004
  • 7
  • 3
1 Solution
 
Meir RivkinFull stack Software EngineerCommented:
the problem is might be the time difference between client and server.
the "remote" server and the client machine should be 10 minutes time of each other.
If that is not the case, a validation will trigger this exception.
make sure the clock on the Server hosting client application is not out of sync with the server having the service.
0
 
rye004Author Commented:
Thank you for replying to my posting.  I did confirm that all my system clocks are synced using the same time.

I also ran the Client and Host on a single machine and still got the same issue.
0
 
rye004Author Commented:
Thank you for your help.
0
Microsoft Certification Exam 74-409

Veeam® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

 
dj_alikCommented:
please perform some checks:

Check timezones: client and servers
may be a service reference/proxy out of date, even with the server & client on the same machine. try to run 'Update Service Reference' for proxy refresh.
Trace your server side.:http://msdn.microsoft.com/en-us/library/ms733025.aspx
Modify Clockskew value  in app.config of client
changed wshttpbinding protocol from "https" to "http"
MessageSecurityException is a generic kind of exception and can be thrown for many problems. To know the real exception we added a serviceDebug behavior to service config and watch the eventviewer for detailed info about the error.
This is the debug config:
<serviceBehaviors>
<behavior name="ServiceBehavior">
 <serviceMetadata httpGetEnabled="false" httpsGetEnabled="true" />
 <serviceDebug includeExceptionDetailInFaults="true" />
 <serviceSecurityAudit auditLogLocation="Application"
  suppressAuditFailure="false"
  serviceAuthorizationAuditLevel="None"
  messageAuthenticationAuditLevel="SuccessOrFailure" />
</behavior>

Open in new window

Check if the Application Pool  have permissions to write at "C:\Windows\Temp"
0
 
rye004Author Commented:
Thank you for taking the time to send me this information.  I am going through what you listed above.  I will let you know what I find.
0
 
dj_alikCommented:
OK
This my checklist.
I gathered for you all methods that may help to solve or find the problem..
0
 
rye004Author Commented:
I am still working on your check list.  I did find the following error in a trace log from the client.  I am currently researching this to see how to get around this.  Any input would be greatly appreciated.

An error occurred while receiving the HTTP response to http://localhost:8000/DistributorService/DistributorService. 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.
0
 
dj_alikCommented:
please get the details...
and please trace the server side.
0
 
rye004Author Commented:
Thank you everyone for your help. Unfortunately I have given up on WCF and switched back to remoting. WCF was not with the effort, sorry.
0
 
rye004Author Commented:
Sometimes you need to go with what works.  There is a lot less issues with using Remoting over WCF.
0
 
rye004Author Commented:
Sometimes you need to go with what works.  There is a lot less issues with using Remoting over WCF.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 7
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now