ArangoDB has two kinds of datafiles for collections:
- the WAL-Files (Write Ahead Log); if new (versions of- ) documents are created this is where they directly go to ensure data is persistently written to disk as fast as possible. This file grows linearily.
- the collection files; one per collection; here we have (older) permanent data.
So if you insert or update documents, they instantly end up in the rolling WAL-files. This is good since spinning disks don't like seeks; so the bursts are written linear into one WAL-file, regardless of which collection they're in. Disks can effectively do their write bursts by grouping write operations in physically narrow areas, and don't need to jump between files (physical places on disk).
Documents are managed by indices that reference them, be they in the data file or the WAL-files. It will also work flawlessly across ArangoDB restarts.
Now to the WAL-Collector thread you're asking about. This thread is here to do the transitions of documents from the wal files into their respective collection files. Since your queries may be working with these documents in other threads, it mustn't move them while it can't make shure they're idle. Therefore it needs to try to get the collection lock for which it intends to migrate the documents for. This may not always work out, and as this may be interesting during the development of ArangoDB it then writes a trace log entry for that. However, sooner or later it should find the time to do so, and once all documents of a WAL-file are migrated, the file can be dropped.
Since this is regular business of ArangoDB - TL;DR:
You can't avoid these messages unless you stop using the trace loglevel and you don't need to wory about it as long as the WAL-files are cleaned up sooner or later.
