none
Sync error for a particular table RRS feed

  • Question

  • Hi All

    We are facing some problem while syncing a large table, for other tables in the database the sync works as expected. I have enabled tracing on the server and I found these errors:

     

    • ·         Type 'Microsoft.Synchronization.Data.DbSyncException' with data contract name 'DbSyncException:http://schemas.datacontract.org/2004/07/Microsoft.Synchronization.Data' is not expected. Add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.
    •  

      ·         The communication object, System.ServiceModel.Channels.ReplyChannel, cannot be used for communication because it has been Aborted.

    • ·         There was no channel that could accept the message with action 'http://tempuri.org/ISyncWebService/BeginSession'.

    • ·         The communication object, System.ServiceModel.Channels.TransportReplyChannelAcceptor+TransportReplyChannel, cannot be used for communication because it has been Aborted

       

      Any help would be really appreciated.

     


    Thursday, April 14, 2011 7:03 AM

Answers

  • if you setting the WCF timeout values for most of the clients, the my guess is that the queries are taking long and WCF timeout fires.  so even if you set the query timeout high, the WCF times out even before the query comes back.

    just post the sync log so we can look at it further.

    Friday, April 15, 2011 10:39 AM
    Moderator
  • Thursday, April 14, 2011 11:53 AM
    Moderator
  • CommandTimeout is a property of SqlSyncProvider so you should be able to set it on both local and remote provider. Just locate where you instantiate the SqlSyncProvider for the server side and set it there.

    Friday, April 15, 2011 7:44 AM
    Moderator

All replies

  • Can you log the inner exception instead? the above exception is pretty much generic and can be caused by lots of things.

    you mentioned this only happens for a particular large table.

    are you using batching?

    have you tried increasing the CommandTimeout property of the sync provider?

    have you checked your WCF settings for message size, timeout, etc if they're big enough or long enough?

    Thursday, April 14, 2011 7:13 AM
    Moderator
  • June,

    I have enabled batching and the timeout is set to max and message size is set to "2147483647".The command timeout of Client Provider is 3 min.

    I have enabled tracing and I have give the switch value to "switchValue" to "Error". 

    I have logged the inner exception for a client and it says “CommunicationException in GetChangeBatch() An error occurred while receiving the HTTP response to http://422biz002.422x.com:81/SyncService/SyncWebService.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. The underlying connection was closed: An unexpected error occurred on a receive. Exception in EndSession() An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail. Error while process on Scope:Activities Object reference not set to an instance of an object’

    For another client the exception is

    "Error while process on Scope:Activities Could not connect to http://Ip Address:81/SyncService/SyncWebService.svc. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond **.***.***.***:81"

     and for yet anothe client it says

    Error while process on Scope:Activities An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail

    All the above error are happening for a particular table, rest all works fine.

     


    Thursday, April 14, 2011 11:01 AM
  • can you enable Sync Fx tracing as well on the server side?

    is your batching directory inside WCF Service's directory? how long does it take before you get the error?

    Thursday, April 14, 2011 11:10 AM
    Moderator
  • The batch directory on server is under "c:\windows\temp" . Can you kindly tell me how to enable Sync Fx tracing.It some times takes 5 min some times immediately and sometimes 15 min and more.
    Thursday, April 14, 2011 11:22 AM
  • Thursday, April 14, 2011 11:53 AM
    Moderator
  • At this point in time do you have any guesses or inputs ?
    Thursday, April 14, 2011 11:56 AM
  • try checking if the iis application pool or worker process is recycling...

    and increase the CommandTimeout on the server as well.

    Thursday, April 14, 2011 12:11 PM
    Moderator
  • Thanks June, Adding send,close,receive,open timeouts in the server config file solved problems for all the clients, however one client is still having a problem with a particular table, I will enable sync tracing tonight.

     

    shall I increase the command timeout of client provider to 5 mins, I dont know how to increase the command timeout for the server provider

    Friday, April 15, 2011 7:23 AM
  • CommandTimeout is a property of SqlSyncProvider so you should be able to set it on both local and remote provider. Just locate where you instantiate the SqlSyncProvider for the server side and set it there.

    Friday, April 15, 2011 7:44 AM
    Moderator
  • Thanks June,

    I have set the command timeout property of both providers to 1800 seconds. But any guesses why the sync fails for that particular table ?. I will post you the sync error log shortly.

    Friday, April 15, 2011 9:17 AM
  • if you setting the WCF timeout values for most of the clients, the my guess is that the queries are taking long and WCF timeout fires.  so even if you set the query timeout high, the WCF times out even before the query comes back.

    just post the sync log so we can look at it further.

    Friday, April 15, 2011 10:39 AM
    Moderator