Without WarmUp, running BatchGet returns nil results and no error, even though the records are present. Using WarmUp before executing the requests seems to alleviate the situation.
The problem seems to be in this piece of code in command.go:2009:
if notFirstIteration {
if !ifc.prepareRetry(ifc, isClientTimeout || err.Matches(types.SERVER_NOT_AVAILABLE)) {
if bc, ok := ifc.(batcher); ok {
// Batch may be retried in separate commands.
retry, err := bc.retryBatch(bc, cmd.node.cluster, deadline, iterations, commandSentCounter)
if !retry {
// Batch was retried in separate subcommands. Complete this command.
if err != nil {
return chainErrors(err, errChain)
}
**return nil**
}
// chain the errors and retry
if err != nil {
errChain = chainErrors(err, errChain).iter(iterations)
}
continue
}
}
}
The executeAt function exits at row 2019 (highlighted above) and by the time we reach the highlighted part (row 2019), we have the following variables:
external err variable: "NO_AVAILABLE_CONNECTIONS_TO_NODE"
retry - false (since this is a single node setup)
err (returned from retryBatch) - nil
The policy has default value for MaxRetries (2) and TotalTimeout (0). It seems like perhaps the retry check should be reversed?
Client:
aerospike-go-client v5.1.0
Server: aerospike/aerospike-server:5.2.0.18 docker container (single node)
Without WarmUp, running
BatchGet
returns nil results and no error, even though the records are present. Using WarmUp before executing the requests seems to alleviate the situation.The problem seems to be in this piece of code in command.go:2009:
The
executeAt
function exits at row 2019 (highlighted above) and by the time we reach the highlighted part (row 2019), we have the following variables: external err variable: "NO_AVAILABLE_CONNECTIONS_TO_NODE" retry - false (since this is a single node setup) err (returned from retryBatch) - nilThe policy has default value for MaxRetries (2) and TotalTimeout (0). It seems like perhaps the retry check should be reversed?