Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support/guidance for multiple hosts #92

Open
SemaphoreSlim1 opened this issue Nov 13, 2024 · 1 comment
Open

Support/guidance for multiple hosts #92

SemaphoreSlim1 opened this issue Nov 13, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@SemaphoreSlim1
Copy link

Is your feature request related to a problem? Please describe.

When configuring RabbitMQ server to run in a quorum, it is common that the nodes are hosted on more than one host.

The RabbitMq.Client library supports failover to these other nodes by accepting a list of endpoints when creating the connection from the connection factory.

It doesn't seem like this client supports this feature

Describe the solution you'd like

As a user of this library, and with no idea how difficult this would be to implement...I'd like to propose the following change:

Instead of calling .Host(...) on ConnectionSettingBuilder, I would call .AddHost(...)

My code would then look like this:

ConnectionSettingBuilder.Create()
                        .AddHost("localhost") //primary node
                        .AddHost("localhost2") //node 2
                        .AddHost("localhost3") //node 3

When failing over from the primary node to another node, I would expect the underlying connection to transition in the following fashion: Open -> Reconnecting -> Open

Describe alternatives you've considered

No response

Additional context

If this feature is already part of this library, or is inappropriate for the 1.0 protocol, please disregard and provide a transition guideline from the existing supported feature of the 0.9.1 AMQP client library

@SemaphoreSlim1 SemaphoreSlim1 added the enhancement New feature or request label Nov 13, 2024
@Gsantomaggio
Copy link
Member

@SemaphoreSlim1 Thank you for raising the issue.

I think that we should accept more endpoints by default like we do in the stream client, WDYT @lukebakken

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants