Spring AMQP has two new connection factories in its next release

(This issue should be scheduled for Boot 2.4; I am not releasing Spring AMQP 2.3 until later in the year but I didn't want to forget about it).

Docs here.

spring.rabbitmq.connection-factory-type

pooledChannel threadChannel caching

Consider defaulting to pooledChannel unless any cache.* properties are explicitly set or the publisher-confirm-type=correlated.

Comment From: iliasmentz

Hello,

is this still up for grabs? Can I give it a try?

Comment From: snicoll

It is. Please go ahead @iliasmentz and let us know how it goes.

Comment From: iliasmentz

hey everyone, I have a question. Is there a way for me to use the non-released spring-amqp by importing it from Gradle?

Comment From: wilkinsona

You should be able to do that by changing the version here to 2.3.0-SNAPSHOT.

Comment From: iliasmentz

You should be able to do that by changing the version here to 2.3.0-SNAPSHOT.

Thanks for your help @wilkinsona! However, there is no available 2.3.0-SNAPSHOT yet. Is there anything else I can try?

Comment From: wilkinsona

It’s available from https://repo.spring.io/snapshot. The build is already configured to use that repository so the version change is all that should be necessary to use 2.3.0 snapshots.

Comment From: snicoll

@iliasmentz how is it going? We're approaching our next milestone soon and I'd like to make sure this one is resolved. Given you're assigned to this issue, can you please give us an update? Thanks!

Comment From: iliasmentz

hey @snicoll, apologies for my late response. to be honest I was kind of lost when I tried to implement it, as I couldn't understand how the properties should decide on which factory should be used because many of them have default values. I would love to give it another try but I would hate to be the bottleneck for the next milestone.

Please let me know how would do you think.

Comment From: snicoll

@iliasmentz thank you for the feedback. The problem is that I didn't really looked at the issue and assumed you had before asking if you could contribute to it.

Looking at it more closely, it isn't certainly easy. I am going to remove the assignment for now. If you find another issue, please let us know and we'll do our best to assist.

@garyrussell this connection-factory is quite impactful as we always assumed CachingConnectionFactory and some configuration properties are specific to this implementation. This leaves us with an odd situation where some properties don't make sense anymore if you chose a different implementation. What we should do there is probably move them to a sub-namespace and deprecate the specific ones in the root namespace.

For instance is-publisher-returns and publisher-confirm-type are on the root. This makes sense considering there is a default method but only 1 implementation out of 3 actually allow to tune that setting. Introducing auto-configuration for the other 2 could be quite misleading with the current arrangement. Thoughts?

Comment From: garyrussell

@snicoll I see - yes; agreed - let's just close this; if someone wants to use one of the new factories they can just define it as a @Bean (disabling auto-config for the default factory).

Comment From: snicoll

Alright. I am going to close this and we can revisit if necessary.