Amqp: Error: Exception (504) Reason: "channel/connection is not open

[Unlym]

go version go1.8
"RabbitMQ","3.2.4", and "RabbitMQ","3.5.7"

I used commit ce1c69d94c3efdb1f287015f851b17db8fa205b1 for few months.

Few days ago I updated package to latest commit. After that I started getting error "channel/connection is not open" in about 1-2 hours after program start

[ERROR] could not add 'q.Name' to queue. Error: Exception (504) Reason: "channel/connection is not open"

[ERROR] code: 505, UNEXPECTED_FRAME - expected content header for class 60, got non content header frame instead, recoverable: false, server: true. Error: RabbitMQ Connection Closed

AMQP connection <0.20002.20> (running), channel 1 - error: {amqp_error,unexpected_frame, "expected content header for class 60, got non content header frame instead", 'basic.publish'}

[Fank]

I can confirm this issue:
ERRO[0011] Exchange Publish: Exception (504) Reason: "channel/connection is not open"
FATA[0011] Exception (505) Reason: "UNEXPECTED_FRAME - expected content body, got non content body frame instead"

RabbitMQ 3.6.11, Erlang 19.2.1
go version go1.8.3 linux/amd64
- name: github.com/streadway/amqp
  version: 2cbfe40c9341ad63ba23e53013b3ddc7989d801c

[Fank]

Got a fix for it by using one channel for publish and one channel for consume.

[marvin5064]

on version afe8eee29a74d213b1f3fb2586058157c397da60, we are facing the same issue

I am wondering if it is related to https://github.com/streadway/amqp/pull/250

[michaelklishin]

@marvin5064 you provide no evidence that #250 is related. Speculations can confuse other users and are not appreciated.

99% of cases where this connection-level error is reported (for any client library) are due to concurrent publishing on a shared channel without proper synchronization.

[michaelklishin]

There is no evidence that this is an issue in this library. As I state above, you can run into it with any client: sharing channels for publishing is not supported by any popular client, and incorrect frame interleaving on the wire is possible in certain other scenarios.

Use a separate channel for publishing and if you publish from multiple goroutines, one channel per goroutine.

[marvin5064]

Use a separate channel for publishing and if you publish from multiple goroutines, one channel per goroutine.

ya, make sense
thank you @michaelklishin 👍🏻

[Eyal-Shalev]

Use a separate channel for publishing and if you publish from multiple goroutines, one channel per goroutine.

@michaelklishin, is it written in the documentation for this library? because if so I couldn't find it. And I've wasted several hours on trying to figure out why my connections keep closing.

If it is not written, maybe add it to the main README.mg file, so that newcomers won't do the same mistake I did.

[dtitov]

So, I've run into the same issue, but I'm already using separate channels for publishing and consumption. Any other possible explanations for this issue?

RabbitMQ 3.8.3
streadway/amqp v0.0.0-20200108173154-1c71cc93ed71

[kopaygorodsky]

@dtitov do you have concurrent acking ?
https://groups.google.com/forum/#!msg/rabbitmq-users/u4AZ2t9enu0/WkDIU9ENAgAJ

I have multiple consumers (each has own channel) and then I multiplex messages onto multiple workers where ack happens in the end. Everything works fine for a long time on prod, I have problems only when I'm debugging my app. It constantly returns 504 error on acking package

[dtitov]

@kopaygorodsky, I've fixed my problem. Initially, I thought that it's fine to have two channels: one for consumption and one for publishing. Apparently, if you publish concurrently, it's better (or maybe even required) to have a channel per publisher (it's, actually, mentioned in the comments above, but I missed it somehow). So now every routine, that publishes something, has its own channel for publishing. And everything works :)

P.S. Can't suggest much regarding ack'ing: I simply use auto-acknowledgments...

P.P.S. Anyway, I agree with @Eyal-Shalev: this should be explicitly mentioned in the documentation.