Skip to content

Conversation

@markusgust
Copy link
Contributor

@markusgust markusgust commented Nov 20, 2025

fixes #225

discussion in slack: https://84codes.slack.com/archives/CGPFUGGS0/p1763573521414509

To be able to set a channel-max on upstream connections. If unset, will default on the brokers configuration, or default to UInt16::MAX if disabled on broker (similar to current behaviour).

Will negotiate the lowest value between what customer specifies and what the broker says to ensure we don't override broker settings.

Will ensure that there is a way to distribute amqproxy connections across if a multi-node cluster is used.

@markusgust markusgust marked this pull request as ready for review November 20, 2025 02:19
@markusgust markusgust requested a review from a team as a code owner November 20, 2025 02:19
Copy link
Member

@spuun spuun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should add support for query parameters in the upstream url instead of new configs? Like we do in amqp-client.cr? channel_max, heartbeat and such.

Signal::TERM.trap &->self.initiate_shutdown(Signal)

server = @server = AMQProxy::Server.new(u.hostname || "", port, tls, @idle_connection_timeout)
server = @server = AMQProxy::Server.new(u.hostname || "", port, tls, @idle_connection_timeout, @max_upstream_channels)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if it's @max_upstream_channels is set to 0? It should probably default to `UInt16::MAX in that case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes setting that to 0 does indeed break amqproxy, and yes that sounds like how it "should" work.

@markusgust
Copy link
Contributor Author

markusgust commented Nov 20, 2025

I wonder if we should add support for query parameters in the upstream url instead of new configs? Like we do in amqp-client.cr? channel_max, heartbeat and such.

If I read it right then we are doing both for idle_connection_timeout for example, which is a bit similar? but also it's not really an amqp parameter so maybe it shouldn't be just the same

edit; noticed it is not working, we are extracting query parameters in

idle_connection_timeout = url.query_params.fetch("idle_connection_timeout", 5).to_i

but we are only sending the value when creating here so we never fetch the value from the URL?:
server = @server = AMQProxy::Server.new(u.hostname || "", port, tls, @idle_connection_timeout)

so instead we should pass the upstream URL and do the parsing in Server.new? then we can extract the query parameter there? then we won't take config items in consideration (unless we merge them to the url beforehand.)

or.. we just take them in the AMQP_URL, pass them to Server.new, and remove the option to use config file for it :)

Copy link
Member

@spuun spuun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I read it right then we are doing both for idle_connection_timeout for example, which is a bit similar? but also it's not really an amqp parameter so maybe it shouldn't be just the same

edit; noticed it is not working, we are extracting query parameters in

idle_connection_timeout = url.query_params.fetch("idle_connection_timeout", 5).to_i

but we are only sending the value when creating here so we never fetch the value from the URL?:

Hm, yeah, the constructor accepting an uri is never used 🤷

We can go with this. If we want to refactor the code in the future it's not a problem, we could still support cli opt/env/config.

Making sure that 0 means UInt16::MAX should be fixed though.

@markusgust markusgust requested a review from spuun December 8, 2025 03:03
Copy link
Member

@spuun spuun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@spuun spuun requested a review from a team December 8, 2025 12:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add configuration parameter for max number of channels used by upstream connections

3 participants