1. 4

  2. 6

    Using a MQ for RPC is a pretty poor idea, IME. It’s a lot of overhead for what should just be opening a socket and communicating back and forth. Things like ProtoBufs and Thrift make this pretty easy, as well.

    The main reason it an MQ for RPC works out poorly, IME, is that RPC is, by all common definitions, a synchronous thing. MQs are all about asynchronicity. It also puts a great big dependency on every component. Where two components could talk directly, now they need a mediator, and if that is down, nothing works. Designing around that basically negates the need for the MQ in the first place.

    1. 1

      Non-durable queues in a direct exchange with multiple round-robin consumers worked well for RPC in a local area in my experience with rabbitmq. It’s a lot easier to add lightweight consumers (RPC workers) and routes (procedures) than using HTTP mechanisms.

      This is not terribly unlike an RPC with Erlang/OTP, even though erlang messsges also are, at the bottom, asynchronous. Participants can be hetergeneous, but supervision, etc. also has to be added rather than out of the box. Rabbit does have some good tools for designing and monitoring.

      The purpose of RPC is to be as lightweight and dynamic as possible, so clustering is not at all appropriate. The intelligence can go in the endpoints, as with HTTP.

      1. 2

        This is not terribly unlike an RPC with Erlang/OTP, even though erlang messsges also are, at the bottom, asynchronous.

        About the only thing I can see it has in common with Erlang/OTP is that there are queues some where. I’m having a hard time seeing where the other similarities are. Erlang does not have a single system all message are moving through (and if goes down, all communication stops). It also doesn’t require crossing a machine barrier to communicate. So it has a completely different failure model and performance model.

        1. 1

          When I write “not terribly unlike” that is intended to mean there’s some significant similarities, but enough differences not to say “alike”.

          How are they alike? Lightweight RPC is fast and easy to set up among many small participants, each a client of rabbit, just as an Erlang process is a client of the messaging system. Running many clients is always easier than running many servers, which is the HTTP setup. So in that core, useful pattern, one can see some significant similarities but not enough to say they are completely alike.

          If you read carefully further, I acknowledge one big difference is the lack of supervision out of the box. As for SPOF, without the trouble of clustering it is not hard at all to have a warm standby. And because the RPC requester is in charge, no message or queue reliability is needed.