SyncOrchestrator w/Proxy Throws Exception When Too Many Updates

All replies

• 

  

  0

  Sign in to vote

  I found the information below in the MSF help file. Is this related? I can see the interface IID is different, but I am wondering if the error above is the same thing.
  
  I'm wondering if this has something to do with the fact that the sample WebSharingAppDemo-CEProviderEndToEnd has the main form application (from where the synchronization is initiated) as well as the webservice running. Are these separate threads within the same process and does that cause this?
  
  You see, the original application that I modified (WebSharingAppDemo-CEProviderEndToEnd) has the SqlCeSyncProvider provider which I suspect means stuff for that provider is executed inline whereas I changed it to use SqlSyncProvider which I am guessing is not.
  
  Any help would be greatly appreciated.
  
  
  

  ---

  Managed Application Throws System.Runtime.InteropServices.COMException (0x80004002)

  A managed synchronization application throws System.Runtime.InteropServices.COMException with the following error message: "Unable to cast COM object of type 'Sync Framework Managed Class' to interface type 'Sync Framework COM Interop Class'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{73EA794F-1251-4466-A19C-DAEAF5BDBD04}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE))."

  This exception occurs when a Sync Framework object is created in one single-threaded apartment and a method of the object is called from a different single-threaded apartment. In this case, the .NET Framework tries to marshal the Sync Framework object from one apartment to the other by querying the Sync Framework object for the IMarshal interface. Sync Framework objects do not implement IMarshal and so the call fails with this exception.

  Solution

  Use multithreaded apartment (MTA) threads. Marshaling is not required for MTA threads.

  Friday, January 22, 2010 6:12 AM
• 

  

  0

  Sign in to vote

  Hi,
  
  I assume that you didn't see this COM exception with the original sample for the same batching setting and the number of records. There is a new MSDN sample for syncing SQL Server and SQL Express: http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=sync&ReleaseId=3762. Instead of modifying the SQL Server with SQLCE sample, can you use new sample instead? Let us know if you get same repro with the new sample still.
  
  For the COM exception, I don't know how you modified the original sample. Did you change it to a MTA application? The original sample is a UI app and run as STA. If you ran your sync in different thread with mismatch thread apartment model, you will hit this COM exception as you has found out.
  
  Also, did you enable Reliable Messaging in your changes? In this case, you need to create your provider and start sync in a MTA thread if your app is not MTA.
  
  Thanks,
  Dong

  ---

  This posting is provided AS IS with no warranties, and confers no rights.

  • Proposed as answer by Dong CaoMicrosoft employee Saturday, January 30, 2010 2:15 AM
  • Marked as answer by Dong CaoMicrosoft employee Tuesday, February 2, 2010 6:28 PM
  • Unmarked as answer by Speedware Saturday, March 13, 2010 4:52 AM
  • Marked as answer by Speedware Monday, March 15, 2010 1:40 PM

  Saturday, January 30, 2010 2:15 AM
• 

  

  0

  Sign in to vote

  Hi,
  
  I assume that you didn't see this COM exception with the original sample for the same batching setting and the number of records. There is a new MSDN sample for syncing SQL Server and SQL Express: http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=sync&ReleaseId=3762. Instead of modifying the SQL Server with SQLCE sample, can you use new sample instead? Let us know if you get same repro with the new sample still.
  
  For the COM exception, I don't know how you modified the original sample. Did you change it to a MTA application? The original sample is a UI app and run as STA. If you ran your sync in different thread with mismatch thread apartment model, you will hit this COM exception as you has found out.
  
  Also, did you enable Reliable Messaging in your changes? In this case, you need to create your provider and start sync in a MTA thread if your app is not MTA.
  
  Thanks,
  Dong

  ---

  This posting is provided AS IS with no warranties, and confers no rights.

  
  I did not modify the apartment model. It is still STA. And I thought that the sample application uses reliable sessions (you said messaging, I assume you meant sessions) because it is a requirement of the contract (at least from my memory). Anyway, here is some more information...
  
  This exception is not limited to the example I modified. My opinion is that whenever certain WCF faults occur, then the local proxy (the object created by the ChannelFactory) causes this exception to be thrown. I believe that my original problem was because of the WCF binding setting <readerQuotas maxArrayLength="1000000" />  which was set much lower per the test example. Other causes are issues with maxReceivedMessageSize, MaxSession and a number of others parameters. Whenever one of these conditions is violated within the WCF session, the remote endpoint sends a fault and this causes the exception.
  
  In my experience over the last month, it strikes me that a remote end point hosted in IIS 6.0 is more stable that a self-hosted service but that is a anecdotal not quantative. As you get your WCF configuration better configured, you cut out the occurrence of this fault.
  
  I do not believe that this is definitively answered and I will unmark it as answered.
  
  FWIW, if you look at WCF traces you can see there are a number of threads running so there are possibilities for cross-thread issues.
  

  • Edited by Speedware Saturday, March 13, 2010 4:57 AM Added comment on reliable sessions..

  Saturday, March 13, 2010 4:51 AM
• 

  

  0

  Sign in to vote

  Hi,
  
  ...
  
  you need to create your provider and start sync in a MTA thread if your app is not MTA.
  
  Thanks,
  Dong

  ---

  This posting is provided AS IS with no warranties, and confers no rights.

  
  Dong,
  
  How would I do that? The GUI needs STA, so how do I start the sync in a MTA  thread?

  • Proposed as answer by Lavanyr Monday, October 25, 2010 2:30 PM

  Saturday, March 13, 2010 5:06 AM
• 

  

  0

  Sign in to vote

  hi steve,
  
  can you try this?
  
  
  Thread t = new Thread(syncThread);
  bool result = t.SetApartmentState(ApartmentState.MTA);
  
  

   

  public static void syncThread()

  {

   

  //do all sync stuff here

  }

  
  
  
  

  Sunday, March 14, 2010 3:34 PM
• 

  

  0

  Sign in to vote

  June,
  
  I did something similar - I used BackgroundWorker because it is a cleaner way of doing this. All of my sync stuff is in a library that the application calls evently using someObjectName.Synchronize(); So, conceptually I have the following:
  
  - Create the background worker
  - Initialize it, hook events
  - Disable the UI
  - Start the thread going.
  
  - The DoWork consists of all of the sync stuff with my library API, but this is where the sync stuff goes.
  
  - The ProgressChanged event is optional. It could be used to update a progress bar.
  
  - The RunWorkerCompleted event could display statistics and would then reenable the UI.
  
  The net result of putting this in a separate thread is now the exception that started this post is displayed for what it is, namely a WCF fault. On my WCF connection, that can be by WCF itself, or by the remote service (where the remote provider is running) and so it could be the remote provider too. At least now the issue is solved.
  
  Steve
  

          private void BackgroundSynchronize_Start()
          {
              this._backgroundSynchronize = new BackgroundWorker();
              this._backgroundSynchronize.DoWork += new DoWorkEventHandler(this.BackgroundSynchronize_DoWork);
              this._backgroundSynchronize.ProgressChanged += new ProgressChangedEventHandler(this.BackgroundSynchronize_ProgressChanged);
              this._backgroundSynchronize.RunWorkerCompleted += new RunWorkerCompletedEventHandler(this.BackgroundSynchronize_RunWorkerCompleted);
  
              this.BackgroundSynchronize_DisableUI();
              this._backgroundSynchronize.RunWorkerAsync();
  }
  
          void BackgroundSynchronize_DoWork(object sender, DoWorkEventArgs e)
          {
  // do sync stuff
  }
  
          void BackgroundSynchronize_ProgressChanged(object sender, ProgressChangedEventArgs e)
          {
              // report on the progress
          }
  
  
          void BackgroundSynchronize_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
          {
              // Display the stats
              this.BackgroundSynchronize_DisplayStats();
  
              // Re-enable the UI.
              this.BackgroundSynchronize_EnableUI();
          }
  

  Monday, March 15, 2010 1:40 PM