Commit 126e4f4
committed
Fixing a doozy of a bug in ReadDB. Full description follows to document.
This issue became apparent when the readFloats method in Bits.java started throwing Socket timeouts after ReadDB was set up on a new data server (and after a move to Java 11). Upon investigation, the bug was only happening when bytesLeftover was non zero and when only a few bytes remained to be read from the stream (typically less than 4). It turned out that both readInts() and readFloats() had lines as follows to calculate how many bytes to read from the stream:
int toread = Math.min(((count - outputpos) * 4), buffer.length - bytesLeftover);
This did not account for a non-zero bytesLeftover value. The lines should have been:
int toread = Math.min(((count - outputpos) * 4)-bytesLeftover, buffer.length - bytesLeftover);
(fixed now)
The effect of this bug was that readInts was occassionally reading too many bytes from the stream, reading into the bytes sent by sendFloats by the relevant ServerTask. This left too few bytes for readFloats(). The data read by readFloats was probably nonsense too.
Why didn't we notice this before?
It seems like this was only an issue in situations where bytesLeftover was non-zero, and that seems to mostly happen when the Client is reading data faster than the ServerTask can send it. The new data server has low latency, so this may be why we only noticed it now (note that the bug was not occurring as frequently from a home connection). Furthermore, the buffer on ServerTask was mistakenly hardcoded as 8192 bytes, whereas the Client had a buffer size of 8192*16. Thus, this also contributed to the Client reading faster than ServerTask was writing.
I don't think this issue would have contributed to erroneous analyses, unless folks were ignoring Socket timeout errors.1 parent dc7ffe3 commit 126e4f4
1 file changed
+0
-1
lines changedThis file was deleted.
0 commit comments