Results 1 to 2 of 2

Thread: Advice regarding RPC/Command pattern in Spring AMQP and Rabbit

  1. #1
    Join Date
    Oct 2011
    Posts
    27

    Default 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. #2
    Join Date
    Jun 2005
    Posts
    4,230

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •