Ensure proper use of Channel-caching in the CachingConnectionFactory [AMQP-43] about spring-amqp HOT 4 CLOSED

Dave Syer commented

#1629 covered the trasnactional semantics for synchronous clients. It uses basicRecover(), so the async clients probably should as well.

from spring-amqp.

Dave Syer commented

One aspect of this problem is that the connection factory does not re-create channels that are closed automatically by the Rabbit client on exception. An easy way to see this is to simply try and access the broker in some "harmless" way, expecting an exception:

template.execute(new ChannelCallback<DeclareOk>() {
	public DeclareOk doInRabbit(Channel channel) throws Exception {
		DeclareOk ok = channel.queueDeclarePassive("test.queue");
		return ok;
	}
});

if the queue doesn't exist there is an exception. Catch it and then try:

admin.declareQueue(new Queue("test.queue"));

this should succeed but fails with {com.rabbitmq.client.AlreadyClosedException} because the template is trying to use the same channel that was closed in the first exception.

from spring-amqp.

Dave Syer commented

I committed a change to the CCF to refresh the channel when it dies after an exception. This has some overlap with #1613 ("connection retry") because it doesn't make sense for some clients to simply ignore a channel closing because it might have exclusive consumers (for instance). It does make sense in some cases though, and it fixes an integration test, so I decided to commit and re-visit when we get to the other retry use cases.

from spring-amqp.

Dave Syer commented

This is now OK after #1613 was fixed.

from spring-amqp.