while($channel->is_open()) issues after previously large batch

[not-art]

Hi y'all,

I did a search for this exact case but couldn't find solutions. My team's running a rabbitmq consumer that is spun up before batch-processing some things. and we publish the messages to. We have our own RabbitMQ cluster internally.

Our processing that publishes to the queue runs in the morning, and in the afternoon.

This works all week, except for Friday afternoon where we have a large batch in the morning- the afternoon job cannot publish any messages.

We're using a single connection, and we close/reopen channels & connection as-needed.

It's almost like there's a max connections limit for the connection, despite closing connections? It seems the morning run on Friday's uses up all connections, then we get nothing but:

RabbitMQ Channel not initialized / PhpAmqpLib\Exception\AMQPConnectionClosedException: Broken pipe or closed connection errors.

Processing continues to work on every other day, but for some reason the next run after a big job does not seem to work (which right now is just Friday afternoons).

Any help is appreciated, thanks!

Our setup:

• AMQPSSLConnection
• PHP 8.1 / latest php-amqplib
• latest Phalcon for our framework
• Our connection is AMQPSSLConnection with verify_peer = false and a 60 second heartbeat
• We're calling checkHeartBeat() before returning the connection
• Our channel/queue (quorum) is defined as followed:

$channel->queue_declare(
                    $queueName,
                    false,
                    true,
                    false,
                    false,
                    false,
                    new \PhpAmqpLib\Wire\AMQPTable(['x-queue-type' => 'quorum'])
                );
$channel->exchange_declare(
                    $exchangeName,
                    \PhpAmqpLib\Exchange\AMQPExchangeType::TOPIC,
                    false,
                    true,
                    false
                );

$channel->queue_bind($queueName, $exchangeName);
return $channel;

[not-art]

This is resolved. We realized a db query on fridays could sometimes run long enough and lock the thread, causing our connection to exceed the 120 second timeout for 2 missed heartbeats. I added logic to reconnect when a broken pipe connection happens on checkHeartBeat() via a try/catch and everything works as-intended now.