This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

AnnouncementAnnouncement Module

Collapse

No announcement yet.

Messages not ACK'd with AcknowledgeMode.AUTO without setting SimpleMessageListenerConPage Title Module

Messages not ACK'd with AcknowledgeMode.AUTO without setting SimpleMessageListenerCon

Sep 20th, 2011, 08:50 AM

I've noticed an issue when writing unit tests that run both Publisher and Consumer threads.

In this scenario(but not if I run consumer and producer as separate processes), when I set the AcknowledgeMode to AUTO on a SimpleMessageListenerContainer, the broker does not appear to recieve an ACK for the recevied message, and after the test shuts down the message is requeued.

But if I set the scope of the SimpleMessageListenerContainer to prototype, I get the correct behaviour.

This is not done in the samples in the docs<http://static.springsource.org/spring-amqp/reference/html/> so I'm wondering if this is some kind of Channel thread-safety issue, or if I'm just doing something wrong?

If it is just the case that SimpleMessageListenerContainer should be scoped as prototype, then can this be documented. And also, if using the <rabbit:listener-container> XML configuration, how would I set the scope?

This was with environment:
spring-amqp -1.0.0-RELEASE
RabbitMQ-2.6.0
Java-1.6.0_26

Your sample test works for me, so there must be something else going on. (Thanks for the code snippet, by the way.) My gugess is you have mouldy exhanges/queues etc. in your broker that are in some way conflicting with the declarations here. I can't really propose an exact scenario where that would make prototype scope have any difference, but since it works for me I can't really offer much else at this stage. Can you try again with a broker reset before you run the test ($ rabbitmqctl reset)?

Comment

Hi Dave. I've tried after a broker reset but still get the same result. But I've just noticed that I had forgotten to comment out the @Scope(value = "prototype") line in the code snippet I posted. ie. the SimpleMessageListenerContainer Bean should have been:

Comment

OK, sorry, I thought the test was supposed to fail. I actually cannot work out how to make this test fail, but I do see the extra message in the queue after the test exits using rabbitmqctl. I think the problem is that you have called container.start() twice (once implicitly when the context starts, and once explicitly in your test method). If you remove that call to container.start(), or change the container config to not start automatically, I think the normal singleton bean is fine. It *is* a bug, but not one that most users will encounter, so not very severe I think. If you can raise a JIRA ticket that would be great.

However, my first attempt to resolve that led to the question whether being able to invoke start() more than once is desirable based on this comment on SMLC's doStart() method:
"Re-initializes this container's Rabbit message consumers, if not initialized already."

That's a bit of a paradox. If it's "RE"-something that implies that something has already happened, but here it says "if not ... already".

Dave, do you know off the top of your head if we can just return without doing anything if 'isRunning' returns TRUE already?