aerospike-client-nodejs: Synchronous error callback in query command causes "unspecified" error in record stream

In our test code we are using AS.query and on error it gives a complete halt of system.

      throw err;

Error: Uncaught, unspecified "error" event. ([object Object])
    at RecordStream.emit (events.js:144:17)
    at /home/ec2-user/testcode/node_modules/aerospike/lib/query.js:315:14
    at Query.foreach (/home/ec2-user/testcode/node_modules/aerospike/lib/query.js:313:11)
    at async.parallel.datasearch (/home/ec2-user/testcode/webnew.js:2301:27)
    at /home/ec2-user/testcode/node_modules/async/dist/async.js:3671:13
    at replenish (/home/ec2-user/testcode/node_modules/async/dist/async.js:884:21)
    at iterateeCallback (/home/ec2-user/testcode/node_modules/async/dist/async.js:869:21)
    at /home/ec2-user/testcode/node_modules/async/dist/async.js:847:20
    at /home/ec2-user/testcode/node_modules/async/dist/async.js:3676:17
    at /home/ec2-user/testcode/node_modules/async/dist/async.js:339:31

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 20 (10 by maintainers)

Most upvoted comments

There are two main differences between batchRead and batchGet:

  1. batchRead uses the newer Batch Index protocol, while batchGet uses the legacy Batch Direct protocol. You can read about the differences between the two protocols here:
  2. batchRead uses asynchronous I/O when communicating with the Aerospike server; batchGet uses synchronous, blocking I/O. In order to provide an async., callback-based API in the JS layer, the batchGet command uses libuv worker threads when communicating with the server. By default, Node.js only uses a worker pool of 4 threads so this can become a bottle neck. I went into a bit more details about the difference between synchronous and asynchronous I/O in a recent blog post, which you can find here:

I would recommend that you upgrade to the v2 as it might address they issues that you are seeing.