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

Listing AMQP 1.0 connections causes crashes that are logged #9371

Closed
lukebakken opened this issue Sep 12, 2023 · 0 comments · Fixed by #9374
Closed

Listing AMQP 1.0 connections causes crashes that are logged #9371

lukebakken opened this issue Sep 12, 2023 · 0 comments · Fixed by #9374
Assignees
Labels

Comments

@lukebakken
Copy link
Collaborator

Describe the bug

Follow-up to #4238 and #5881

Reproduction steps

  1. Start an AMQP 1.0 (git@github.com:lukebakken/Amqp10SessionExample.git) and AMQP 0.9.1 connection to RabbitMQ
  2. Run rabbitmqctl list_amqp10_connections
  3. Everything appears to work, but the log file will show the following:
    2023-09-12 04:39:57.314641-07:00 [error] <0.940.0>   crasher:
    2023-09-12 04:39:57.314641-07:00 [error] <0.940.0>     initial call: rabbit_reader:init/3
    2023-09-12 04:39:57.314641-07:00 [error] <0.940.0>     pid: <0.940.0>
    2023-09-12 04:39:57.314641-07:00 [error] <0.940.0>     registered_name: []
    2023-09-12 04:39:57.314641-07:00 [error] <0.940.0>     exception exit: {unexpected_message,{info,[pid],<0.1030.0>}}
    2023-09-12 04:39:57.314641-07:00 [error] <0.940.0>       in function  rabbit_reader:handle_other/2 (rabbit_reader.erl, line 640)
    2023-09-12 04:39:57.314641-07:00 [error] <0.940.0>       in call from rabbit_reader:mainloop/4 (rabbit_reader.erl, line 531)
    2023-09-12 04:39:57.314641-07:00 [error] <0.940.0>       in call from rabbit_reader:run/1 (rabbit_reader.erl, line 453)
    2023-09-12 04:39:57.314641-07:00 [error] <0.940.0>       in call from rabbit_reader:start_connection/5 (rabbit_reader.erl, line 352)
    

Expected behavior

No crashes in the log file.

Additional context

https://vmware.slack.com/archives/C055BSG8E/p1694516973608289

@ansd -

Things "appear" to be fine. But the underlying issue is how 1.0 connections are queried. 1.0 readers and 0.9.1 readers hang in the same position in the supervisor tree and have the same ID reader, hence that PR lists all 0.9.1 connections and all 1.0 connections.

@lukebakken lukebakken added the bug label Sep 12, 2023
lukebakken added a commit that referenced this issue Sep 12, 2023
Fixes #9371

Moves `pg_local` to `rabbit_common`
lukebakken added a commit that referenced this issue Sep 12, 2023
Fixes #9371

Moves `pg_local` to `rabbit_common`
lukebakken added a commit that referenced this issue Sep 12, 2023
Fixes #9371

Moves `pg_local` to `rabbit_common`
lukebakken added a commit that referenced this issue Sep 12, 2023
Fixes #9371

Moves `pg_local` to `rabbit_common`
lukebakken added a commit that referenced this issue Sep 12, 2023
Fixes #9371

Moves `pg_local` to `rabbit_common`
lukebakken added a commit that referenced this issue Sep 12, 2023
Fixes #9371

Since each AMQP 1.0 connection opens several direct AMQP connections, we
must assign each direct connection a unique name to prevent multiple
entries in the `connection_created_stats` table.

Also, use `pg_local` to track AMQP 1.0 connections instead of walking
the supervisor trees.
lukebakken added a commit that referenced this issue Sep 12, 2023
Fixes #9371

Since each AMQP 1.0 connection opens several direct AMQP connections, we
must assign each direct connection a unique name to prevent multiple
entries in the `connection_created_stats` table.

Also, use `pg_local` to track AMQP 1.0 connections instead of walking
the supervisor trees.
lukebakken added a commit that referenced this issue Sep 12, 2023
Fixes #9371

Since each AMQP 1.0 connection opens several direct AMQP connections, we
must assign each direct connection a unique name to prevent multiple
entries in the `connection_created_stats` table.

Also, use `pg_local` to track AMQP 1.0 connections instead of walking
the supervisor trees.

Nuke authz_backends from connection created event 💥
lukebakken added a commit that referenced this issue Sep 14, 2023
Fixes #9371

Since each AMQP 1.0 connection opens several direct AMQP connections, we
must assign each direct connection a unique name to prevent multiple
entries in the `connection_created_stats` table.

Also, use `pg_local` to track AMQP 1.0 connections instead of walking
the supervisor trees.

Nuke authz_backends from connection created event 💥
lukebakken added a commit that referenced this issue Sep 15, 2023
Fixes #9371

Since each AMQP 1.0 connection opens several direct AMQP connections, we
must assign each direct connection a unique name to prevent multiple
entries in the `connection_created_stats` table.

Also, use `pg_local` to track AMQP 1.0 connections instead of walking
the supervisor trees.

Nuke authz_backends from connection created event 💥

Fix regex for connection name because UniqueId is part of it now (channel number)
lukebakken added a commit that referenced this issue Sep 15, 2023
Fixes #9371

Since each AMQP 1.0 connection opens several direct AMQP connections, we
must assign each direct connection a unique name to prevent multiple
entries in the `connection_created_stats` table.

Also, use `pg_local` to track AMQP 1.0 connections instead of walking
the supervisor trees.

Nuke authz_backends from connection created event 💥

Fix regex for connection name because UniqueId is part of it now (channel number)
mergify bot pushed a commit that referenced this issue Sep 16, 2023
Fixes #9371

Since each AMQP 1.0 connection opens several direct AMQP connections, we
must assign each direct connection a unique name to prevent multiple
entries in the `connection_created_stats` table.

Also, use `pg_local` to track AMQP 1.0 connections instead of walking
the supervisor trees.

Nuke authz_backends from connection created event 💥

Fix regex for connection name because UniqueId is part of it now (channel number)

(cherry picked from commit c94d22a)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants