Problem with automatic reconnect master, slave

[s4ndr0ne]

Hi, when the connection to the master node occurs, sometimes if the connection connects to the slave the consumers remain blocked, the only way to make it resume is to restart the application. Can it happen? Is it possible to trap the ConnectionClosedException or ConsumerClosedException error through an event such as for connection restored? I couldn't figure out if it stops working when those two exceptions occur (ActiveMQ.Artemis.Client.Exceptions.ConsumerClosedException: The Consumer was closed due to an unrecoverable error. AMQ119015: not authorized to create consumer). I think it connects but the server has not yet been restored and it would be useful if recovery was set to ignore the exception

[Havret]

Hi @s4ndr0ne,

Thanks for reporting this. I’ll look into it and check with the broker team to see if this behavior is expected during failover.

Best,
Havret

[Havret]

Hi @s4ndr0ne,

Thanks for raising this issue. I checked with the broker team regarding the behavior you described.

Summary of findings:

• The broker should only accept client connections after all services (including security settings) have been fully initialized. This means that a consumer should not be able to connect before the broker is ready.
• Any runtime security changes made via the management API are supposed to be replicated to the backup before the broker responds to the caller. So, if no error was returned when applying security settings, the changes should be reflected on the backup node as well.
• This behavior is not expected during failover. If the broker rejects consumer creation due to an AMQ119015: not authorized to create consumer error, it suggests a potential issue that warrants further investigation.

Possible Explanation:

• Security permissions are only checked when a consumer is first created. If authorization rules changed after a consumer was originally created, these changes won’t take effect until the consumer reconnects (e.g., during failover).
• While it's technically possible that the backup broker isn’t fully initialized when the client attempts to connect, this would be a bug that should be fixed.

Next Steps:

To investigate further, the best approach would be to try reproducing this behavior in a controlled test scenario. If you can provide a minimal test case that consistently triggers the issue, it would greatly help diagnose whether this is a client-side or broker-side problem.

Let me know if you have any additional details!

Best,
Havret

[s4ndr0ne]

Hi Havret,

Thank you for raising this issue and for sharing the details.

I will try to reproduce the case in a controlled test environment as suggested. However, I believe there might have been some manual configuration errors during the reconnection test, which I cannot control as I am not the broker manager.

Currently, I am managing reconnection in service disruption cases by restarting the pod if the health check detects that the connection is closed or the retry policy not work.

I will continue to monitor the situation and keep you updated on the results of my tests.

Thanks again for your support.

Best regards,
Alessandro