Announcement Announcement Module
No announcement yet.
Implementing the Worker pattern in AMQP Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Implementing the Worker pattern in AMQP

    I'm trying to implement the Worker pattern using the Spring AMQP API and not making much headway.

    Very simply, I want a queue like this:

    Client sends a request -> Exchange -> routed to single Queue 'Q1'

    Several Worker 'handlers' should peel off the requests from the queue and 'handle' them. Since the handling can take time, we want that the requests to be handled by the next available worker. So if a free worker is available, then the request is handled immediately, else it waits for a worker to get free.

    Using the Spring AMQP API, I'm thinking I should set up a SimpleMessageListenerContainer on the 'Worker' side. However, that container only allows me to set one 'Listener' on it.
    How can I make is so that I can have a variable number of listeners and that they are cycled as described above?

    Thanks in advance!

  • #2
    The "listener" is a stateless object invoked when a message arrives.

    Concurrency is controlled by the setConcurrentConsumers method - see the JavaDocs.

    Note that the concurrency may be further limited if you inject a custom TaskExecutor that limits the number of threads.


    • #3

      Thanks.. that was it!

      Somewhat related: Is there a way to change the concurrency on a container at run-time?

      So, I want to increase/decrease the number of workers while the broker and ListenerContainer is up? What do I need to do to make that happen?

      Is that why the jmx stuff is on the amqp-stocks example? (I don't see the tie-in at all of how the jmx exposed bean (in stocks example) is being used.)



      • #4
        No, JMX on the listener container just exposes the active consumer count as a read-only attribute; see the @ManagedMetric annotation on getActiveConsumerCount().

        The AMQP listener container does not currently support dynamic modification of the concurrency. Nor does it support auto resizing the consumers between a min and max (like the JMS listener container does).