Closed matsakiv closed 1 year ago
Hi @matsakiv, thanks for your investigation and PR to fix. I beleave there is no problem with Aes algothims works with multiples of PAGE_SIZE.
I will made same tests, but in this case, I almost sure that this "ENSURE" are wrong. Just remove can works fine. I made this lot of ENSURE to test internal conditions and better track bugs. Sometime this ENSURE can be wrong for same specific case.
Version LiteDb: 5.0.16 OS: MacOS Darwin (Kernel 21.2.0) .NET: 5.0.17
Describe the bug When trying to call
OrderBy
while reading data from the collection, an error occurs with the messageLiteDB ENSURE: buffer size must be PAGE_SIZE
. Database uses password/encryption and the number of records in collection is large (over 10000 entries).It looks like the problem is that in some cases the
SortService
class can use multiple containers and use a Stream File in methodInsert
. By default container size is8192*100=819200
bytes. But if encryption is used then in the AesStream.Write method there is a hard restriction that the size of the incoming buffer must be exactly equal to thePAGE_SIZE=8192
.If the number of records multiplied by the size of the sorting key exceeds the size of the container (
819200
) thenSortService
is guaranteed to use the file system and an error occurs.This is the location of the call to write to disk in
SortService
:This results in a call to the
Write
method of theSortDisk
class:And in the end it leads to a fall in
AesStream
:if I understand correctly, it can be fixed by the multiplicity requirement
containerSize % PAGE_SIZE == 0
and multiple writer calls for each block of sizePAGE_SIZE
.StackTrace from Sentry logs:
Code to reproduce