Testing Guranteed Delivery

[vveludan]

Dave to avoid confusion I have begun using new exchange and new queue.
using the same configuration as before

<bean id="messageListenerContainer" class="org.springframework.amqp.rabbit.listener.Si mpleMessageListenerContainer">
<property name="connectionFactory" ref="connectionFactory" />
<property name="queueName" value="rabbitmq.test.queue"/>
<property name="concurrentConsumers" value="1" />
<property name="messageListener" ref="messageListenerAdapter" />
<property name="channelTransacted" value="true" />
<property name="acknowledgeMode" value="AUTO"/>
</bean>


In AbstractMDBRabbitConfiguration: tried with both SingleConnectionFactory and CachingConnectionFactory:
@Bean
public ConnectionFactory connectionFactory() {
//CachingConnectionFactory connectionFactory = new CachingConnectionFactory(rabbitMQHost);
SingleConnectionFactory connectionFactory = new SingleConnectionFactory(rabbitMQHost);
connectionFactory.setUsername(rabbitMQUser);
connectionFactory.setPassword(rabbitMQPassword);
//connectionFactory.setChannelCacheSize(1);
return connectionFactory;
}


Now messages are not at all saved to the disk/queue on failure of RabbitMQ broker.

Thanks
Venkat

[Dave Syer]

[QUOTE=vveludan;350593
This is strange, if I consume messages with RabbitMQ API consumer,
can't reproduce the problem.
[/QUOTE]

What version of the broker do you have (rabbitmqctl status tells you). It should be 2.3.1 (the latest). Otherwise there was a bug in the broker that prevented messages from being delivered to a restarted MessageListenerContainer.

[vveludan]

Good morning Dave.
I am using RabbitMQ version 2.0. That could be the problem. I will work with the version 2.3.1. I appreciate and thank you for the feed back.

Thanks
Venkat

[vveludan]

Dave I have updated RabbitMQ Broker to 2.3.1 version. Also updated OTP Erlang to otp_win32_R14B01 and RabbitMQ Java client to 2.3.1. After these updates I have rerun the test.
Following are my observations with 1.0.0M3:
- Bring up RabbitMQ Broker
- Bring Message Listener Container.
- Publish 100 Messages.
Dave Simple Message Listener Container is not responding at all to the oublished messages. It is up and running but when messages are put in the queue. It simply does not process. In other words the handler never get executed.

Following are observations with 1.0.0M2:
- Bring up Broker
- Bring up Message Listener Container
- Publish 100 messages.

Messages are consumed without any problem.

The other observation is:

-Have Broker running
- Have Listener Running.
- Publish 100 messages
- Bring down messages after 10 messages consumed.
- Bring up Broker and check for messages_ready
- It shows 100 instead of 90. That is fine. The good thing is messages are saved when the broker is down. When I bring up Listener it process messages in the queue. Though 10 messages are reprocessed (considered as duplicate messages), at least messages are not lost when the broker is down. With M2 I could not set acknowledgeMode = TRUE as it was throwing:
org.springframework.beans.NotWritablePropertyExcep tion: Invalid property 'acknowledgeMode'.

The drawback of M2 is, when I bring down RabbitMQ Broker, Message Listener Container gets terminated silently without throwing any exception.

Coming back to M3, Dave could you please let me know what's happening with Message Listener Container. As I mentioned earlier, it's up and running but never pick up messages from queue to process.

I appreciate and thank you for your time.

Venkat

[Dave Syer]

Coming back to M3, Dave could you please let me know what's happening with Message Listener Container. As I mentioned earlier, it's up and running but never pick up messages from queue to process.

All I can say is it works for me (and everyone else). Can you grab the samples and verify that they work? Run the integration tests?

[vveludan]

Good morning Dave.
As per your suggestion I will run samples and integration tests.

Thanks
Venkat

[vveludan]

Good afternoon Dave.
The test project I am running is not using log4j. Therefore running spring-amqp components are executed in debug enabled mode by default.
In org.springframework.amqp.core.Message.getBodyConte ntAsString() method:
if (MessageProperties.CONTENT_TYPE_SERIALIZED_OBJECT. equals(contentType)) {
return (String) SerializationUtils.deserialize(body);
}

In my case deserialize method is returning DMBMessage object, here it is
type casting to String. This was throwing ClassCastException.

This code was made use in: org.springframework.amqp.rabbit.listener.handle() method as follows:
if (logger.isDebugEnabled()) {
logger.debug("Received message: " + message);
}

As I mentioned earlier that my test code is getting executed in debug enabled mode always and logger.debug() statement was causing ClasscastException. Therefore, my MessageListener is running and not processing any messages that are published to the queue.
I placed a log4j.properties in the project and set:
log4j.logger.org.springframework.amqp=ERROR

After this I could run MessageListener without any problems.
I have also tested RabbitMQ Broker Hard failure test. Messages are saved to the queue when I bring down the broker. When I bring up the broker and Message Listener, messages are consumed.

Thanks
Venkat

[vveludan]

Dave there was a typo mistake in the following line
This code was made use in: org.springframework.amqp.rabbit.listener.handle() method as follows:

The class name I am trying to point is:
org.springframework.amqp.rabbit.listener.BlockingQ ueueConsumer.handle(Delivery delivery) method.

Thanks
Venkat

[Dave Syer]

Ah, finally we can make progress. Thanks for finding the bug (https://jira.springsource.org/browse/AMQP-124). You can report bugs yourself in JIRA and then you will be able to track it to completion. Probably we should be more defensive in Message.toString().