Instead of literally asking to a node all values for givent `h`, we first ask
for all ids the node has. Then, we concurently and individually ask for each
values that match each id we recovered in our first request.
Since bootstrapSearch was rewritten to use the node cache, it made it clear that
refill should be rewritten as such. However, then bootstrapSearch becomes
irrelevant.
An enhancement to refill is that it will let insertNode review its whole list
of nodes and then let it insert nodes up to SEARCH_NODES nodes. The previous
method would not garantee this behavior since, most of the times, it would pass
less than SEARCH_NODES nodes to insertNode.
The number of currently requested nodes, formerly named currentGetRequests, was
renamed since it was not accurately describing the behavior. The number we are
counting is not the number of 'get' requests, but rather the number of nodes
being requested simultaneously.
When a 'get' request associated with a certain 'query' has been sent, we don't
want to send it again, i.e. we don't care if it's pending or not as soon as it
has been sent.
Each time a 'listen' request is sent to the network engine, we track this
request in the upper layer with a map<shared_ptr<Query>, shared_ptr<Request>>.
At some point, this map has to be maintained or totally cleared. However, it was
done wrong, hence the sendListen loop. Clearing a pair <Query, Request> has to
be done when the API user cancels a 'listen' operation.
Since the elements inside are going to be moved constantly during the life of
the node, this design is better. Also, it works around a crash when the store is
resized (elements inside moved) at some point (always happenned the 3rd time)
for some reason. This bug was known when compiled with LLVM >7.3.0 (>clang-703.0.31).
When querying from local storage with SELECT f, a FieldValueIndex with empty
fields was returned without considering the SELECT statement requiring only a
field "f".
Simon Désaulniers
Adrien Béraud
kaldoran
Nicolas
Andreas Traczyk