I have been testing DOScan with live traffic simultaneously hitting the database. At high enough throughput (~700/s), the scan simply stalls. I have multiple threads doing live traffic (get + updates). one thread scanning the keys, with the following config. For each such key it obtains in the scan, it does a get()In your post I see the JE DiskOrderedCursor producer thread, but I don't see your thread that is using the DiskOrderedCursor and calling getNext. As far as I can tell, the scan is stalled and other operations are blocked because DiskOrderedCursor.getNext is not being called. The producer thread is blocked because its queue is full, because it is not being emptied by DiskOrderedCursor.getNext.
Do you think the DO Producer should release the lock on the btree if blocked on the queue?Access to the Btree is blocked until the seeding phase is finished. This is very unlikely to change.
This was basically done so that we fetch the value only when its an interesting key.If the ratio of values-fetched/keys-scanned is small, then this could have a big positive performance benefit. But if this ratio is close to 1, it will have a big negative performance impact, since the fetches of the value will be random IOs.