I had this issue before months ago, but then couldn't reproduce it
anymore. Now I had this problem again in production code and now found
a way to reproduce this:
What I'm doing in the production code is, that I get a batch of files
which I need to store in RavenFS. The files are sent over the wire and
to reduce the amount of data transferred, I check the MD5 first and
skip the file if it already exists with the same MD5.
What happens when I have couple of hundred of files is, that RavenDB
locks up and stays at about >80% CPU load until I kill the process.
Sometimes this happens after all files have been read, sometimes I even
don't get so far and reading the file header blocks at some point.
The log then gets spammed with entries like:
2017-12-12T11:15:37.1137329Z;INFO;<system>;Raven.Client.Changes.RemoteChangesClientBase`3;Sending
command watch-conflicts - to
http://localhost/fs/DefaultFileSystem
with id 1/6VkD1U3Tuvn/-
I could reproduce this with a couple of lines of code:
https://gist.github.com/anonymous/dc796bd01ef58f67ba2179a20a6e2f08
Snippet:
for (var i = 0; i < 500; i++)
{
Console.WriteLine($"Reading foo.bin #{i}");
using (var asyncFilesSession = store.FilesStore.OpenAsyncSession())
{
var fileHeader = await
asyncFilesSession.LoadFileAsync("foo.bin").ConfigureAwait(false);
//The following line seems to help:
//await
asyncFilesSession.Commands.UpdateMetadataAsync("foo.bin",
fileHeader.Metadata).ConfigureAwait(false);
}
}
If I reduce the number of times I read the file header from 500 to e.g.
10, then I don't see this issue.
My current workaround is, that I write the metadata back after reading
the file header, which somehow seems to make this work.
Am I doing something completely wrong here or is this a bug?
Tobias