-
-
Notifications
You must be signed in to change notification settings - Fork 200
Description
Hello,
I have had a strange problem when default size of update batch was too long to execute in default timeout period. Had to adjust settings to fix it, but problem that I'd like to report here is that timeout error was eaten by DotMim.Sync without giving any hints to my application about that.
It looks like timeout is treated as transient error by DotMim.Sync and it retries transaction. If another timeout happens, it retries again and so on. It looks like by default there is no limit about amount of retries that should be performed. And DotMim.Sync doesn't log those errors in default logging settings (by IProgress) - so to see them I had to adjust SyncOptions.ProgressLevel.
I think ability for the user to set max number of retries would be nice (and give it some reasonable default, not infinite). I have added it myself for my application by creating a new class based on SqlSyncChangeTrackingProvider and overriding bool ShouldRetryOn(Exception exception).
By the way: Another strange thing is that if updates are retried, than the same writes that were previously done, are executed again, but percentage in current progress doesn't go back. Net effect is that if transient errors cause retries than current progress indicator goes above 100%. I have had infite retries, so my percentage went realy high after few hours.