Issue with using "amqp" package after upgrading to OTP26

Questions / Help
1

After upgrading to OTP26, our app that uses amqp package fails to establish a connecting to RabbitMQ server, and I am failing to understand why. Connecting to OTP25 works fine.

# OTP25
AMQP.Connection.open("amqp://guest:guest@amqp-issue-rabbitmq")
{:ok, %AMQP.Connection{pid: #PID<0.241.0>}}

# OTP26
AMQP.Connection.open("amqp://guest:guest@amqp-issue-rabbitmq")
# => {:error, {:auth_failure, 'Disconnected'}}

I have a hunch this must be related to recent changes to SSL-specific defaults in OTP26. However, attempts to disable ssl_options doesn’t work either - it fails with another error, so I must be passing the options in a wrong way. For example, this fails:

AMQP.Connection.open("amqp://guest:guest@amqp-issue-rabbitmq", [ssl_options: :none])
# => {:error, :econnrefused}
Reproduction details

The reproduce script is this one:

# sample.bash
mix do local.hex --force, local.rebar --force

elixir -e 'Mix.install([:amqp]); AMQP.Connection.open("amqp://guest:guest@amqp-issue-rabbitmq") |> IO.inspect()'

The full reproduce experiment is this one:

docker network create amqp-issue

docker run \
  --rm \
  --name amqp-issue-rabbitmq \
  --detach \
  --network amqp-issue \
  rabbitmq:3.11.16-alpine

sleep 5 # give rabbitmq enough time to fully initialize

docker run \
  --rm \
  --name amqp-issue-otp25 \
  --network amqp-issue \
  --mount type=bind,source=$(realpath sample.bash),target=/tmp/sample.bash \
  hexpm/elixir:1.14.1-erlang-25.1.2-alpine-3.16.2 \
  ash /tmp/sample.bash

docker run \
  --rm \
  --name amqp-issue-otp25 \
  --network amqp-issue \
  --mount type=bind,source=$(realpath sample.bash),target=/tmp/sample.bash \
  hexpm/elixir:1.14.4-erlang-26.0-alpine-3.18.0 \
  ash /tmp/sample.bash

docker stop amqp-issue-rabbitmq

docker network rm amqp-issue

I haven’t dig too deep into amqp_client yet. Any ideas what might be preventing the connection and how to fix it? :thinking:

3 Likes
2

you must probably need to have a version of the server that supports otp26
for reference

1 Like
3

you must probably need to have a version of the server that supports otp26

Would that not be somewhat counter-intuitive? I mean, since it’s a client that’s having issues, and the only connection between client and server is done via TCP and using a well-establish message queue protocol :thinking:

4

The client implementation and the server share code, according to this note in that second Github issue:

Note that rabbit_net:port_command/2 is not only used by RabbitMQ server, but also by the AMQP 0.9.1 client. Therefore, instead of putting the OTP version (or send function) into persistent_term within the rabbit app, we just do it the first time rabbit_net:port_command/2 is invoked.

1 Like
5

Fair enough :+1: Still can’t wrap my head around how that change would affect client in the connection scenario specifically though