0

I'm using RabbitMQ as message broker as publisher/subscriber, but sometimes I receive the following error:

Message has been rejected: Warning: Error while sending QUERY packet. PID=5987 in /var/www/html/vendor/magento/zendframework1/library/Zend/Db/Statement/Pdo.php on line 228

I think that this occure because the connection with MySQL stays open and when exceed wait_timeout = 500 from my.cnf the next message cause me this error. Now, how can I avoid this? Is there a way to close connection from my consumers?

  • Did you ever solve this? Running into the exact same problem. – Peter Jaap Blaakmeer Oct 25 at 11:54
0

This post "Symfony2 and RabbitMQ: lessons learned" does a nice job of explaining the problem (replace Symfony with Magento and it's still valid);

Because the consumer is one process that keeps running, that also means that the service container and stuff keeps existing in memory. When you’ve done some queries the database connection keeps open in the background. And if it’s quiet on our queue, it may take some time before we reach the message limit. If that time exceeds the connect_timeout of your MySQL server, you’ll run into the warnings and errors about lost connections.

Of course we should close the connection after the message is processed or could try catch for Doctrine DBAL connection exceptions or increase the connect_timeout setting but thats just denying the real problem. Running consumers with a booted Symfony2 kernel just doesn’t work so well.

So in short; when the queue isn't (very) busy, the MySQL connection stays open for a longer period thereby exceeding MySQL's timeout. When the queue is busy however, it'll hit the message limit for one connection and create a new connection, avoiding the timeout.

Two short term options; 1. Raise the MySQL timeout (but to what? that depends on how 'busy' your system is). 2. Lower the message limit per connection. I'm not sure how to do this.

I don't know about a long-term solution where we can both tailor the not-so-busy moments and the busy moments and avoid the time-out altogether without sacrificing performance in busy moments.

Edit; after re-reading your initial post and understanding the issue better, I now see you already realized exactly this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.