Note to self: I should not have mentioned the JMS aspect 😬

The JMS client provides a callback for the AMQP ConnectionFactory (setAmqpConnectionFactoryPostProcessor), ...

I just checked that and: com.rabbitmq.client.ConnectionFactory does not expose methods to set a BlockedListener(the only listeners one can set are #setTrafficListener and #setErrorOnWriteListener unless I miss something)

EDIT: Re-reading your comment I think this was the point your were trying to make...It's not possible at the moment without a customization callback for the actual com.rabbitmq.client.Connection

But regardless of what the JMS client library can or cannot do:

What are your thoughts about tracking the number of blocked connections in the metrics? This would benefit both the 'vanilla' client library and JMS clients. I'd be happy to push my prototype as a PR

Here are my thoughts about collecting blocked connections in a metric:

• it means adding a new method to the MetricsCollector. It's a breaking change in theory, but we can use a default method in the implementation.
• all the existing MetricsCollector should (must) be updated.
• the metric may not be always accurate (a blocked connection may get closed without the unblock callback). We may be able to keep the blocked state with a flag to avoid this though.
• there is no strong demand for this (first time since we introduced metrics collection in 2016).
• anyone interested in this can use a BlockedListener with their own metric.

I find it overly complicated over a simple connection callback in the JMS client.

@michaelklishin Your thoughts on this?

it means adding a new method to the MetricsCollector. It's a breaking change in theory, but we can use a default method in the implementation.

Really? Isn't com.rabbitmq.client.MetricsCollector#newConnection enough?

from my experiments in com.rabbitmq.client.impl.AbstractMetricsCollector

@Override
 public void newConnection(final Connection connection) {
 try {
 if(connection.getId() == null) {
 connection.setId(UUID.randomUUID().toString());
 }
 incrementConnectionCount(connection);
 connectionState.put(connection.getId(), new ConnectionState(connection));
 connection.addShutdownListener(cause -> closeConnection(connection));
 // => adding the listener to the new connection
 connection.addBlockedListener(this::incrementBlockedConnectionCount, this::decrementBlockedConnectionCount);
 } catch(Exception e) {
 LOGGER.info("Error while computing metrics in newConnection: " + e.getMessage());
 }
 }

But you are right:

It's surely possible to subclass e.g. MicrometerMetricsCollector, override newConnection and add the blocked listener there.

Thanks for your detailed response!

I'll give the subclassing and metric creation a shot 👍

With the connection creation callback they could provide their own blocked listener, and even plug onto other extension points.

Would you like me to create an (issue/discussion) in the JMS client repo regarding this? Again I'd be more than happy to give it a try with a PR

I don't think you need to subclass anything: create a metric from the Micrometer registry you pass into the metrics collector, keep a reference of this metric and use it in the blocked listener you add to your connections.

Sure, let's move this to the JMS client repository, you can create a PR directly. Thanks!