URI Query Parameters

[Tensho]

I found nor bunny neither amqp-protocol support URI query parameters in the connection string. Particularly AMQ::URI.parse method just grabs connection vital options. Is it intentionally?

It's easier to configure one env var instead of several (host, port, vhost, etc). Particularly, I would like to provide client heartbeat value within connection string instead of parameters map.

[michaelklishin]

There's been little demand for entirely URI-driven configuration so far. I'd be happy to accept a PR with improvements as long as someone can first demonstrate what it would look like.

[Tensho]

@michaelklishin, I'd happy to create PR, but first I would like to specify URI options here and confirm it with you. I will base on RabbitMQ official documentation "URI query parameters" page and Python RabbitMQ client Pika "Connection Parameters" page. If you know any other valuable related resources, please don't hesitate to refer me.

[michaelklishin]

Some parameters are client-specific, others we don't care about. See Bunny::Session for the list of what's actually being used. Bunny::Transport is another place I'd look at.

[michaelklishin]

Realistically you can only support values that are numerical, strings or symbols (that can get pretty confusing, fast), so I'd ignore stuff such as client properties entirely. The guide on rabbitmq.com lists options that are supported by the Erlang client and therefore Federation and Shovel plugins. I don't think it's essential for Bunny to use the same names but it'd be nice.

[Tensho]

Sure, I will consult Bunny::Session and Bunny::Transport modules and try to understand them :) I agree about compliance with the set of parameters RMQ Erlang client uses itself, but just in sake of my enlightenment could you give an example of client-specific (bunny) parameter?

[michaelklishin]

Channel operation timeout is not on the URI reference, fail_if_no_peer_cert is not an option you can configure in Bunny (although enabling peer verification effectively does that).

[Tensho]

Thank you for the quick feedback, @michaelklishin 🙇

[Tensho]

RabbitMQ Documentation	Bunny::Session	Description
cacertfile, certfile, keyfile	tls_ca_certificates, tls_cert, tls_key	Paths to files to use in order to present a client-side SSL certificate to the server. Only of use for the amqps scheme
verify, fail_if_no_peer_cert	verify_peer	Use to configure verification of the server's SSL certificate. See the SSL guide for details of SSL in RabbitMQ in general and specifically the Erlang client section. Only of use for the amqps scheme.
auth_mechanism	auth_mechanism	SASL authentication mechanisms to consider when negotiating a mechanism with the server. This parameter can be specified multiple times, e.g. ?auth_mechanism=plain&auth_mechanism=amqplain, to specify multiple mechanisms.
heartbeat	heartbeat	Heartbeat timeout value in seconds (an integer) to negotiate with the server.
connection_timeout	connection_timeout	Time in milliseconds (an integer) to wait while establishing a TCP connection to the server before giving up.
channel_max	channel_max	Maximum number of channels to permit on this connection.

So here, in amq-protocol gem, I'd like to introduce the parameters described above to conform RabbitMQ official documentation. I guess all other bunny specific parameters (read_timeout, write_timeout, recovery_attempts, etc.) should be parsed at bunny uri parsing level. Does such segregation make sense?

[michaelklishin]

@Tensho provided that we can just pass a hash around and merge the two, then use it as the existing hash of options, it does. amqp gem will then have to potentially be updated as well (even though it does not get much use and attention these days).

[Tensho]

Yes, I'd like to parse at different levels depending on parameters adoption and then merge common parameters hash and client specific parameters hash. I don't mind to update all 3 gems – amq-protocol, bunny, amqp.

[michaelklishin]

Addressed in #67. Thank you.

[Tensho]

Thank you, @michaelklishin 🙇