Announcement Announcement Module
Collapse
No announcement yet.
Advice regarding RPC/Command pattern in Spring AMQP and Rabbit Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Advice regarding RPC/Command pattern in Spring AMQP and Rabbit

    Hi

    I'm looking for advice on how to handle non-replies from consumers, and also to detect if there are no consumers running.

    I'm using Spring Integration + AMQP for a Command pattern where multiple producers issue commands to a consumer. The commands are issued over AMQP/RabbitMQ. I have this running, but I'm having trouble with the error handling.

    I'd like the producers to timeout and raise an error if they don't receive a response. Also I don't want these commands to be queued by the Rabbit exchange so that it is not sent to the producer when it restarts.

    I tried different settings on the queues and exchanges but in the end I found the only way I could achieve this is to have the consumer context create the Rabbit exchange bean, and to set autoDelete to true and to make it non-durable. The producer contexts then instantiate the beans but not the exchange bean. This means if the consumer shuts down it will the exchange is deleted and clients will start getting errors when they try to publish commands to it.

    This works but was wondering if there is a another way to detect and handle these errors.

    Kind regards
    David/

  • #2
    For pure RPC with Spring Integration that's probably the best approach to the requirements you have. RPC is a bit of a dirty word with the messaging purists, and Rabbit is very much in that camp, so you don't get much love trying to tweak it. There are richer features in the broker that might be very relevant (publisher confirms being the most important probably), but they aren't part of the AMQP protocol so they don't (yet) have explicit support in Spring, except by manipulating the Channel itself directly. These features tend to be asynchronous though, so not well suited to blocking RPC, and would require quite a lot of state management on the clients for reliable operation.

    Comment

    Working...
    X