Question

I have to listen for rpc calls , stack them somewhere , process them, and answer. The thing is that they are not run as soon as they come. The response is an ACK for each rpc call recieved.
The problem is that i want to design it in a way that i can have many listening servers writing in the same stack of calls, piling them up as they come.

My objective is to listen to as many calls as possible. How should i achieve this?

My main technology is Perl and node.js but would use any open source software for this task.

Answer 1

It sounds like any kind of job queue will do what you need it to; I’m personally a big fan of using Redis for this kind of thing. Since Redis lists maintain insertion order, you can simply LPUSH your RPC call info on to the end of the list from any number of web servers listening to the RPC calls, and somewhere else (in another process/on another machine, I assume) RPOP (or BRPOP) them off and process them.

Since Node.js uses fully asynchronous IO, assuming you’re not doing a lot of processing in your RPC listeners (that is, you’re only listening for requests, sending an ACK, and pushing onto Redis), my guess is that Node would be exceedingly efficient at this.

An aside on using Redis for a queue: if you want to ensure that, in the event of a catastrophic failure, jobs are not lost, you’ll need to implement a little more logic; from the RPOPLPUSH documentation:

Pattern: Reliable queue

Redis is often used as a messaging server to implement processing of background jobs or other kinds of messaging
tasks. A simple form of queue is often obtained pushing values into a
list in the producer side, and waiting for this values in the consumer
side using RPOP (using polling), or BRPOP if the client is better
served by a blocking operation.

However in this context the obtained
queue is not reliable as messages can be lost, for example in the case
there is a network problem or if the consumer crashes just after the
message is received but it is still to process.

RPOPLPUSH (or
BRPOPLPUSH for the blocking variant) offers a way to avoid this
problem: the consumer fetches the message and at the same time pushes
it into a processing list. It will use the LREM command in order to
remove the message from the processing list once the message has been
processed.

An additional client may monitor the processing list for
items that remain there for too much time, and will push those timed
out items into the queue again if needed.