Description:
Per Frazer:
In a multi-threaded API node where threads 1 and 2 are not interacting with Ndb directly but they are using thread 3 as a 'DB worker' thread.
Thread 3 is defining PK/UK operations, sending them asynchronously and polling for results. Thread 3 can be extended to also define scan operations and send them asynchronously. Once a scan operation has been executed, the results are iterated with calls to nextResult().
The nextResult() API will return rows in the currently 'cached' batches to the caller. When there are no more rows available in the current 'cached' batches, nextResult() needs to ask the data nodes for more batches, which it will do if the fetchAllowed parameter is true. This is a synchronous operation. It will get the next batch(es) of rows for the scan operation it is called upon.
It will not :
- Request any more batches for other scan operations
- Execute any defined PK / UK operations
- Return control to the caller until the batch(es) are available.
How to repeat:
Having Thread 3 iterate results will cause Thread3 to be unresponsive while it is making a blocking call to nextResult() for one of it's scans.
Suggested fix:
We would need to define some asynchronous Api extensions for use with scans so that :
- A request for more batch(es) can be sent asynhronously
- pollNdb() can 'wakeup' when the requested batch(es) are available.
This would allow :
- Thread 3 to request and wait for other work while scan results are being iterated
- More than 1 scan to be advanced in parallel by a single thread.
