Artem Bilan

Isn't that what is supposed to be configured on the binder level via `spring.cloud.stream.kafka.binder` properties: https://docs.spring.io/spring-cloud-stream/reference/kafka/kafka-binder/config-options.html ?

Right. So, it feels like fix has to be done in Kafka Binder itself.

Let's add @sobychacko , since I'm not fully on board how Kafka Binder works.

This has nothing to do with Micrometer by itself. @jonatan-ivanov , please, consider to close this in favor of: https://github.com/spring-projects/spring-integration/issues/9191. Thanks

The NIO is just part of Java SDK anyway, and extra imports for those gives a little impact. Moving the NIO part into a helper class would bring much more...

The `RepublishMessageRecoverer` in Spring AMQP has a logic like: ``` /** * Subclasses can override this method to add more headers to the republished message. * @param message The failed...

That's wrong assumption. Better to check docs before going into the woods: https://docs.spring.io/spring-integration/reference/html/jdbc.html#supported-databases. Hibernate and Hikari has nothing to do with this `LockRepository` implementation. I'd suggest you to back off...

If you don't use any other Spring Integration JDBC features, you don't need other tables, just that `INT_LOCK`. For contributing such a support back to the framework, please, look first...

Thanks, Gary, for sharing your mind! Those both use-case are really achievable by some other intuitive structures like you have just explained. We do use those bridges in those cases...

Going to deprecate right now for `6.5`, give some field battle testing before removing in the next `7.0`.