batchGet() hangs if connection closes and there are outstanding call backs

[aerospike]

batchGet() hangs if connection closes and there are outstanding call backs

[GayathriKaliyamoorthy]

Hi,

client.close() should be invoked only when all the operations that are performed using the client object is completed. The semantics of client.close() is release all the resource associated with client object. The resources include all the open connections and memory allocated for the client object. Once these resources are released, the client can no longer communicate with Aerospike Server and thus the processing stops.

In the above code snippet, you are not waiting for callback to be invoked by the client.batchGet(tweet_keys,function(terr,tresults){} for this batchGet invocation. The client.close() function must be invoked after processing this inner callback.

Thanks.

[denisbetsi]

Absolutely, I realize that. I am just saying that, those call backs in the forloop do not get terminated, the code gets stuck in the forever unending dead end. If the connection drops for whatever reason and has similar functionality to client.close() will it mean that worker with all those unresolved call backs be stuck the same way?

[GayathriKaliyamoorthy]

@denisbetsi

Regarding the connection dropping for any reason, the underlying driver handles that case. Client object stores the callback passed for the batchGet API and invokes it when the operation is completed. If the client object is destroyed, then the behavior is undefined.

Thanks