Ensure proper use of Channel-caching in the CachingConnectionFactory [AMQP-43]

[spring-operator]

Mark Fisher opened AMQP-43 and commented

Consider transactions vs. non-transactional channels (keep separate since TX will always apply once started)

Consider the role of the Channel for async consumers (esp. on "rollback"... do we call basicRecover() or close()?)

---

No further details from AMQP-43

[spring-operator]

Dave Syer commented

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

[spring-operator]

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.

[spring-operator]

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.

[spring-operator]

Dave Syer commented

This is now OK after #1613 was fixed.