-
Notifications
You must be signed in to change notification settings - Fork 108
Description
Consistent EOF error happens if the reading position is keeping up with the writing position and if the write rolls a file, then read will throw an EOF error since it missed its chance to roll.
It is to do with how the reader rolls, it checks after it has read a message if it should roll to the next file and when it checks it uses a variable that is called maxBytesPerFileRead
. The variable is either the files size if the file is complete or the maxBytesPerFile
which is configured (e.g 100 MB).
Say readFileNum = d.writeFileNum
and maxBytesPerFile = 100 MB
Say we read Msg-1 and after which the nextReadPos
is at 96 MB, this is under maxBytesPerFile (100 MB)
so we don’t roll.
Then say we write Msg-2 which is 10 MB. It doesn’t fit so we roll the write file and write the message in the new file. Then we set maxBytesPerFileRead = 96 MB
Now when we read we get an EOF error as there is no more data in the file and we missed our chance to roll when we read Msg-1.
Because we hit an EOF we will mark the file as bad and roll to the next file, so we are not missing any messages but we accumulate a lot of unnecessary bad files.
This problem however doesn’t present itself if the reader is more than a message behind the writer, because after the writer has rolled there are still messages in the previous file for the reader to read. He will then be able to use the updated maxBytesPerFileRead
value when reading those messages.
A fix is to move the check for roll at the start of the readOne
function and roll before we read if necessary.