Amqp: Excepción (504) Motivo: "el canal / conexión no está abierto"

Creado en 24 ene. 2014  ·  12Comentarios  ·  Fuente: streadway/amqp

cuando publico el mensaje, el código devuelve el error Excepción (504) Razón: "el canal / conexión no está abierto". para que es el error

Comentario más útil

Hola amigos,

Tengo el siguiente código...

// Connect - Connects to RabbitMQ
func (queue *Queue) Connect(args ...interface{}) {

    var uri string

    if args == nil {

        // Get from env vars
        uri = os.Getenv("RABBIT_MQ_URI")

        if uri == "" {
            log.Panic("No uri for queue given")
        }
    } else {
        uri = args[0].(string)
    }

    // Make max 5 connection attempts, with a 1 second timeout
    for i := 0; i < 5; i++ {

        log.Println("Connecting to:", uri)

        // If connection is successful, return new instance
        conn, err := amqp.Dial(uri)

        if err == nil {
            log.Println("Successfully connected to queue!")
            channel, _ := conn.Channel()
            queue.Connection = conn
            queue.Channel = channel
            return
        }

        log.Println("Failed to connect to queue, retrying...", err)

        // Wait 1 second
        time.Sleep(5 * time.Second)
    }
}

// Declare a new queue
func (queue *Queue) Declare(queueName string) (amqp.Queue, error) {
    return queue.Channel.QueueDeclare(
        queueName,
        true,
        false,
        false,
        false,
        nil,
    )
}

// Publish a message
func (queue *Queue) Publish(queueName string, payload []byte) error {
    return queue.Channel.Publish(
        "",
        queueName,
        false,
        false,
        amqp.Publishing{
            DeliveryMode: amqp.Persistent,
            ContentType:  "application/json",
            Body:         payload,
        },
    )
}

// Listen for a new message
func (queue *Queue) Listen(queueName string) (<-chan amqp.Delivery, error) {
    return queue.Channel.Consume(
        queueName,
        "",
        true,
        false,
        false,
        false,
        nil,
    )
}

Luego en mi main.go

        // Get queue connection
    queue := drivers.NewQueue()
    queue.Connect()

        // Declare new queue for submissions 'stuff'
    _, err = queue.Declare("submissions_queue")

    if err != nil {
        log.Panic(err)
    }

    // We need to declare the responses queue even though we're not actually
    // going to use it on the bot side as an emitter.
    _, err = queue.Declare("submissions_responses")

    // Log out any queue errors
    if err != nil {
        log.Panic(err)
    }

Estas colas luego interactúan con una aplicación PHP heredada (Laravel). Lo cual funciona perfectamente durante uno o dos días, luego, después de aproximadamente un día, a veces menos, a veces más, empiezo a recibir este Exception (504) Reason: "channel/connection is not open" . ¿Alguna pista? ¿Estoy haciendo algo tonto?

¡Gracias por adelantado!

Todos 12 comentarios

Es probable que el canal que está utilizando esté cerrado, explícitamente o debido a una excepción de canal. Inspeccione el registro de RabbitMQ para obtener más información.

@eimugray, si nos proporciona un estuche de reproducción, podemos ayudarlo. El error más común es que ha intentado declarar una cola o un intercambio de forma diferente a lo que existe actualmente en el servidor.

Como dice Michael, revise los registros del servidor.

Hola amigos,

Tengo el siguiente código...

// Connect - Connects to RabbitMQ
func (queue *Queue) Connect(args ...interface{}) {

    var uri string

    if args == nil {

        // Get from env vars
        uri = os.Getenv("RABBIT_MQ_URI")

        if uri == "" {
            log.Panic("No uri for queue given")
        }
    } else {
        uri = args[0].(string)
    }

    // Make max 5 connection attempts, with a 1 second timeout
    for i := 0; i < 5; i++ {

        log.Println("Connecting to:", uri)

        // If connection is successful, return new instance
        conn, err := amqp.Dial(uri)

        if err == nil {
            log.Println("Successfully connected to queue!")
            channel, _ := conn.Channel()
            queue.Connection = conn
            queue.Channel = channel
            return
        }

        log.Println("Failed to connect to queue, retrying...", err)

        // Wait 1 second
        time.Sleep(5 * time.Second)
    }
}

// Declare a new queue
func (queue *Queue) Declare(queueName string) (amqp.Queue, error) {
    return queue.Channel.QueueDeclare(
        queueName,
        true,
        false,
        false,
        false,
        nil,
    )
}

// Publish a message
func (queue *Queue) Publish(queueName string, payload []byte) error {
    return queue.Channel.Publish(
        "",
        queueName,
        false,
        false,
        amqp.Publishing{
            DeliveryMode: amqp.Persistent,
            ContentType:  "application/json",
            Body:         payload,
        },
    )
}

// Listen for a new message
func (queue *Queue) Listen(queueName string) (<-chan amqp.Delivery, error) {
    return queue.Channel.Consume(
        queueName,
        "",
        true,
        false,
        false,
        false,
        nil,
    )
}

Luego en mi main.go

        // Get queue connection
    queue := drivers.NewQueue()
    queue.Connect()

        // Declare new queue for submissions 'stuff'
    _, err = queue.Declare("submissions_queue")

    if err != nil {
        log.Panic(err)
    }

    // We need to declare the responses queue even though we're not actually
    // going to use it on the bot side as an emitter.
    _, err = queue.Declare("submissions_responses")

    // Log out any queue errors
    if err != nil {
        log.Panic(err)
    }

Estas colas luego interactúan con una aplicación PHP heredada (Laravel). Lo cual funciona perfectamente durante uno o dos días, luego, después de aproximadamente un día, a veces menos, a veces más, empiezo a recibir este Exception (504) Reason: "channel/connection is not open" . ¿Alguna pista? ¿Estoy haciendo algo tonto?

¡Gracias por adelantado!

Consulte los registros del servidor para conocer las excepciones de canales: cierran canales. También cierres abruptos de la conexión TCP del cliente. Este cliente no proporciona recuperación de conexión automática por diseño, esa es su responsabilidad de la aplicación.

Actualicé mi código donde a veces se produce el error de publicación en cola, para volver a crear el canal e intentarlo de nuevo, ¿es eso lo que quiso decir?

El único resultado que veo es:

[bot-rmq-1]2016-11-23T10:27:42.499711789Z =INFO REPORT==== 23-Nov-2016::10:27:42 ===
[bot-rmq-1]2016-11-23T10:27:42.499718307Z closing AMQP connection <0.14157.0> (<redacted>:39617 -> <redacted>:5672)
[bot-rmq-1]2016-11-23T10:27:42.705177619Z 
[bot-rmq-1]2016-11-23T10:27:42.705206764Z =INFO REPORT==== 23-Nov-2016::10:27:42 ===
[bot-rmq-1]2016-11-23T10:27:42.705212691Z accepting AMQP connection <0.14215.0> (<redacted>:39622 -> <redacted>:5672)
[bot-rmq-1]2016-11-23T10:27:43.046378706Z 
[bot-rmq-1]2016-11-23T10:27:43.046413103Z =INFO REPORT==== 23-Nov-2016::10:27:43 ===
[bot-rmq-1]2016-11-23T10:27:43.046419515Z closing AMQP connection <0.14180.0> (<redacted>:51242 -> <redacted>:5672)
[bot-rmq-1]2016-11-23T10:27:43.253073052Z 
[bot-rmq-1]2016-11-23T10:27:43.253103233Z =INFO REPORT==== 23-Nov-2016::10:27:43 ===
[bot-rmq-1]2016-11-23T10:27:43.253109057Z accepting AMQP connection <0.14227.0> (<redacted>:51243 -> <redacted>:5672)
[bot-rmq-1]2016-11-23T10:27:45.950046536Z 
[bot-rmq-1]2016-11-23T10:27:45.950085091Z =INFO REPORT==== 23-Nov-2016::10:27:45 ===
[bot-rmq-1]2016-11-23T10:27:45.950091135Z closing AMQP connection <0.14215.0> (<redacted>:39622 -> <redacted>:5672)
[bot-rmq-1]2016-11-23T10:27:46.147715611Z 

En realidad, no veo ninguna excepción en ningún lado hasta ahora

Sí, las aplicaciones necesitan abrir otro canal y usarlo, no hay otra forma. La recuperación automática de la conexión en otros clientes lo asigna conservando la identificación del canal, pero en lo que respecta a RabbitMQ, es un canal completamente separado.

Su registro sugiere que las conexiones se cierran <5 segundos después de que se aceptan. Las conexiones RabbitMQ (con cualquier protocolo de mensajería) están destinadas a ser de larga duración: ¿está seguro de que su propio código no conlleva un alto grado de rotación de conexiones? Si además de eso es concurrente, no es difícil ver cómo una cosa intenta hacer algo mientras se cierra una conexión. Por lo tanto, intente utilizar conexiones de larga duración, en particular si ya ha implementado la recuperación de canales.

Impresionante, ¡salud por tu ayuda! No estoy usando intencionalmente una conexión de corta duración, tal vez algo, en algún lugar, está cerrando prematuramente la conexión. Tendré que profundizar más en mi código.

Los errores de nivel de conexión de graves " en el lenguaje del protocolo) son raros y deberían ser muy visibles en el registro del corredor. Por lo general, indican errores de cliente con serialización o concurrencia.

tal vez se haya creado su nombre de cola.

Tuve este problema, resulta que el servidor rabbitmq no estaba encendido. así que tal vez verifique eso

Problema al que se enfrenta : No se pudo publicar un mensaje: Excepción (504) Motivo: "el canal / conexión no está abierto"

He comprobado los registros en rabbitMQ
2020-07-30 11:55:57.792 [error] <X.XXXX.86> Channel error on connection <X.XXXX.86> (XX.XXX.XX.X:42801 -> XX.XX.X.XX:4672, vhost: '/', user: 'openapi-gateway'), channel 1: operation basic.publish caused a channel exception not_found: no exchange 'api-log-aggregator' in vhost '/' 2020-07-30 11:55:58.327 [warning] <X.XXXX.86> closing AMQP connection <X.XXXX.86> (XX.XXX.XX.X:42801 -> XX.XX.X.XX:4672, vhost: '/', user: 'openapi-gateway'):

según los registros anteriores, api-log-aggregator no se ha implementado, por eso recibí un error, así que implementé el servicio api-log-aggregator y volví a implementar
Funcionó bien ...

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

pnuz3n picture pnuz3n  ·  17Comentarios

kpurdon picture kpurdon  ·  22Comentarios

cenkalti picture cenkalti  ·  4Comentarios

michaeljs1990 picture michaeljs1990  ·  11Comentarios

janika picture janika  ·  9Comentarios