Description
While we document that N1QL handles must be close()-d when the statement is done. But JS being a garbage collected language, it is very easy to forget this, especially when there is a clearly defined scope enclosing the query.
Consider this function:
function onUpdate(doc, meta) {
|
var query = SELECT * from `keg-list` WHERE `keg-id` = doc.keg_id;
|
var today = new Date();
|
for (var keg of query) {
|
if (keg.due_date > today) processBeers();
|
}
|
}
|
|
function processBeers(keg_id) {
|
var query = SELECT * from `beer-samples` WHERE `keg-id` = keg_id;
|
for (var beer of query) {
|
var ok = .... some logic ...
|
if (ok) return;
|
}
|
}
|
This will throw exceptions unpredictably due to running out of handles because the handles opened by processBeers() is not cleared when the function exits.
While all JS users understand it is a garbage collected language and the collection is not deterministic, there is an implied expectation that the GC is reasonable. The problem with N1QL is that we don't adhere to this basic assumption because handles are leaked until the handler thread exits the OnUpdate/OnDelete even when the GC is properly cleaning up intermediate resources.
Attachments
Issue Links
- backports to
-
MB-38403 [BP MB-39079] Closing N1QL iterators that have been GC'd
- Closed