scope definition for a MessageListenerAdapter(and POJO) for concurrent listeners

[sbelvadi]

Should the MessageListenerAdapter bean and associated POJO delegate bean have prototype scope when the listener container is configured to have concurrent consumers? If it is not defined as prototype will the listener container provide new instance of MessageListenerAdapter and POJO. Am not clear how this is done. Appreciate clarifications.

thanks

[Gary Russell]

It's just like any other <bean/>. If it's thread-safe you can use the default singleton scope. The general recommendation is to keep beans thread-safe whenever possible.

[Gary Russell]

I should clarify - the bean MUST be thread-safe (regardless of scope) when using more than one listener container thread - only one instance is injected into a container, regardless of scope.

[sbelvadi]

Thanks for the quick response. Just so I understand, in the configuration I am using below:

<rabbit:listener-container id="workFlowListenerContainer"
        connection-factory="connectionFactory" concurrency="${rabbitmq_concurrent_consumers}">
        <rabbit:listener id="workFlowMsglistener" queues="monitorSvcQueue"
            ref="workFlowMsgListenerAdapter" />
    </rabbit:listener-container>

    <bean id="workFlowMsgListenerAdapter"
        class="org.springframework.amqp.rabbit.listener.adapter.MessageListenerAdapter"
        scope="prototype">
        <property name="delegate" ref="workFlowMsgProcessor" />
    </bean>

    <bean id="workFlowMsgProcessor" class="com.fedex.cloud.ops.vcops.amqp.WorkFlowMessageProcessor"
        scope="prototype" />

Even though I have defined the scope of workFlowMsgListenerAdapter and workFlowMsgProcessor to be prototype, the listener container is injected with a single instance of each of these beans when the application context is loaded.

So, when the listener container is trying to boot up multiple consumers/listeners, is it sharing the same instance of the message processor (Pojo) between all the concurrent consumers or is it internally creating new instances of the listener adapter and delegate pojo? Is my definition of the scope for the listener adapter and pojo unnecessary in this case.

I guess I just don't have a handle on how the rabbit:listener-container or for that matter a jms Listener Container instantiates multiple concurrent consumers/listeners and associated handlers/Pojo to process messages.


Sorry for my elementary questions.
Appreciate your input.

Thanks

[Gary Russell]

This is really no different to any Spring configuration - a prototype bean simply means a new instance is used each time it is referenced. So, if you inject it into 2 other beans, each gets its own instance. In addition, if you use context.getBean(...), you'll get a new instance each time.

Since the container (<rabbit:listener/>) is simply a <bean/> that gets a reference to the listener, it only gets one instance so, yes, in this case, the scope makes no difference.

If your WorkFlowMessageProcessor is not thread-safe, set the concurrency to 1 and add multiple <rabbit:listener/> elements - then you'll get a separate container, each with its own instance of the listener.

[sbelvadi]

Thanks for your clarifications and patience. i have a better understanding of prototype scope now.

[dariovmartine]

This is really no different to any Spring configuration - a prototype bean simply means a new instance is used each time it is referenced. So, if you inject it into 2 other beans, each gets its own instance. In addition, if you use context.getBean(...), you'll get a new instance each time.

Since the container (<rabbit:listener/>) is simply a <bean/> that gets a reference to the listener, it only gets one instance so, yes, in this case, the scope makes no difference.

If your WorkFlowMessageProcessor is not thread-safe, set the concurrency to 1 and add multiple <rabbit:listener/> elements - then you'll get a separate container, each with its own instance of the listener.

Then this solution is for use in long process like pipeline ?

[Gary Russell]

I don't understand your question; sorry. This thread is all about bean scoping when used as a ChannelListener.

Please don't add new questions to existing threads; please start a new thread (and clarify what you are asking).

[dariovmartine]

I thought in which cases you uses concurrents consumers using same bean's instance.

[Gary Russell]

I still don't understand your question; sorry. It should be clear from this discussion that a listener container uses a single bean instance, regardless of its scope. This has no bearing on how long it takes to process a message.

It's simple, if your bean is thread-safe, you can use more than one thread. If it's not, you need a separate container for each instance if you need to concurrently process more than one message.

In this context, by thread-safe, I mean a well-designed, mostly (or preferably completely), stateless bean (little or no shared state and any shared state is only locked for very short periods). If your bean has so much state that you have to add synchronized to all or most of the method that handles the message then, while it might be thread-safe, it would completely defeat any concurrency settings of the container.

Bottom line - if your handler is designed for concurrency you can use concurrency; if it's not, you can't.