I'm designing a system which listens to JSON RPC calls from clients, piles them up inside a list, and if the list gets full it will store them in a DB and keep receiving calls.

My original plan is to listen to the RPC calls from Perl with the JSON-RPC and put them in an array. The clients do some long polling in another server to get responses as they appear.

  • What is this blocking/non-blocking thing?
  • Should I do a script for node.js to listen to the calls?
  • What do you think is a good practice in this case?

The goal is to listen as much calls as possible.

  • 1
    You got two answers to blocking/non-blocking because the question is ambiguous. In one context it refers to the message patter (send request, wait for reply) vs (send request, provide callback address or poll for result). The second involves code that must wait for relatively long running operations to complete and therefor the process or thread is blocked by the kernel until such time as the operation is complete. For example, reading from the disk will cause the process to block until data is ready. – ipaul Mar 20 '13 at 3:43

It sounds to me that using a message queue (MQ) would be ideal for you here.

piles them up inside a list, and if the list gets full it should store them in a DB and keep receiving calls.

An MQ can be thought of as a first-in first-out storage service. The way it works is that rather than piling up your service requests and managing them internally, you would write them to the queue and have your server process poll the queue to see if there are any messages to process.

What is this blocking/non-blocking thing?

Blocking / Non-blocking refers to the time it takes for an operation to complete blocking the thread from running. For example, IO and network operations are a common blocking bottleneck.

Using a message queue would allow you to largely avoid blocking as they're generally quick (given being located on the same network) and will allow you to fire the RPC call and continue with your processing.

If you need to process a result this gets more complex and where you would consider mechanisms such as a result queue that you poll, invocation of a remote script, etc.


Blocking or non-blocking is about whether or not you want to wait for a call to complete. Non-blocking calls typically do work on another thread so the thread invoking it can resume doing other stuff. Blocking calls are more common. One reason to make a blocking call is wanting to make sure the call succeeded without error before continuing on the next thing.

I can't tell you to use node.js or not. I don't think the technology matters, you could do this with most programming environments.

What you describe basically is buffering. I would do it non-blocking unless something is really expensive (maybe parsing the rpc call is). This way you guarantee you won't miss any call.

If you do it non-blocking, because there is significant work, I would use a thread pool for it, typically they end up blocking if the pool can't keep up.

You will need to synchronize with some locking to allow multiple threads to store stuff in your buffer (that's why I'd rather do it blocking on a single thread) and you will lose ordering of your calls which may or may not be important.

Using a double buffer you can flush your buffer to the DB while also still receive new calls. You may need to lock shortly while flipping buffers after a flush.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.