Session loss: No batchPartInfo could found for the current sessionId

Hi,

if we have a long sync (~40min) at the end we always get this exception. What could this be?

Error during Config sync

Dotmim.Sync.Web.Client.HttpSyncWebException: Session loss: No batchPartInfo could found for the current sessionId. It seems the session was lost. Please try again.

---

---

INNER EXCEPTION

Session loss: No batchPartInfo could found for the current sessionId. It seems the session was lost. Please try again.

at Dotmim.Sync.Web.Server.WebServerOrchestrator.HandleRequestAsync(HttpContext httpContext, Action1 action, CancellationToken cancellationToken, IProgress1 progress)

at Dotmim.Sync.Web.Client.HttpRequestHandler.<HandleSyncError>d__15.MoveNext() — End of stack trace from previous location where exception was thrown — at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task) at Dotmim.Sync.Web.Client.HttpRequestHandler.<SendAsync>d__14.MoveNext() — End of stack trace from previous location where exception was thrown — at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Dotmim.Sync.SyncPolicy.<InternalExecuteAsync>d__171.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task) at Dotmim.Sync.Web.Client.HttpRequestHandler.<ProcessRequestAsync>d__12.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task) at Dotmim.Sync.Web.Client.WebClientOrchestrator.<ApplyThenGetChangesAsync>d__36.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task) at Dotmim.Sync.SyncAgent.<>c__DisplayClass53_0.<<SynchronizeAsync>b__0>d.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Dotmim.Sync.SyncAgent.<SynchronizeAsync>d__53.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter1.GetResult() at Geeks.Pos.DataModel.PosDBSync.<SyncConfigAsync>d__16.MoveNext()

[gentledepp]

Hi! This exception was actually introduced by me as I found an issue in Dotmim.Sync.

• When uploading changes in batches, the client sends each batch part in a separate request.
• On the server-side, all those batches are stored on disk
• only when the last batch file is uploaded, all those files are deserialized and the changes they contain are applied to the database in one transaction.
• To know which files belong together, DMS stores a batchPartInfo in the session - which is normally just an in-memory cache.

So should this session be cleared (e.g. IIS decides to recycle an application pool which can happen once in a while), this batchPartInfo is suddenly lost.

If we did not throw this exception, all previous batch files would never be applied to the database. So you would in fact lose changes and not even know about it. This was really a critical issue for us and our customers.

So this exception is actually a good thing as it will cause the client to re-send all batches.

[gentledepp]

@matevzcesar I am not entirely sure. First, please check what kind of session implementation you use.

It could also be, that you have a scaleout scenario (two or more web servers) and you did not configure a distributed cache like redis. If the first batch is then transmitted to server 1, but the second to server 2 you would have the same issue.

Or, your session is kept for e.g. 5 minutes (in the cache), but you sync too much data. => session is cleared, and you lose your batchPartInfo

In other words: I just do not know enough about your setup to tell you what is going on.