{"id":1971,"date":"2022-08-30T15:20:58","date_gmt":"2022-08-30T15:20:58","guid":{"rendered":"https:\/\/unknownerror.org\/index.php\/2013\/12\/06\/php-fpm-processes-holding-onto-mongodb-connection-states-collection-of-common-programming-errors\/"},"modified":"2022-08-30T15:20:58","modified_gmt":"2022-08-30T15:20:58","slug":"php-fpm-processes-holding-onto-mongodb-connection-states-collection-of-common-programming-errors","status":"publish","type":"post","link":"https:\/\/unknownerror.org\/index.php\/2022\/08\/30\/php-fpm-processes-holding-onto-mongodb-connection-states-collection-of-common-programming-errors\/","title":{"rendered":"PHP-FPM processes holding onto MongoDB connection states-Collection of common programming errors"},"content":{"rendered":"<p>For the relevant part of our server stack, we&#8217;re running:<\/p>\n<ul>\n<li>NGINX 1.2.3<\/li>\n<li>PHP-FPM 5.3.10 with PECL mongo 1.2.12<\/li>\n<li>MongoDB 2.0.7<\/li>\n<li>CentOS 6.2<\/li>\n<\/ul>\n<p>We&#8217;re getting some strange, but predictable behavior when the MongoDB server goes away (crashes, gets killed, etc). Even with a <code>try\/catch<\/code> block around the connection code, i.e:<\/p>\n<pre><code>try\n{\n    $mdb = new Mongo('mongodb:\/\/localhost:27017');\n}\ncatch (MongoConnectionException $e)\n{\n    die( $e-&gt;getMessage() );\n}\n\n$db = $mdb-&gt;selectDB('collection_name');\n<\/code><\/pre>\n<p>Depending on which PHP-FPM workers have connected to mongo already, the connection state is cached, causing further exceptions to go unhandled, because the <code>$mdb<\/code> connection handler can&#8217;t be used. The troubling thing is that the <code>try<\/code> does not consistently fail for a considerable amount of time, up to 15 minutes later, when &#8212; I assume &#8212; the php-fpm processes die\/respawn.<\/p>\n<p>Essentially, the behavior is that when you hit a worker that hasn&#8217;t connected to mongo yet, you get the die message above, and when you connect to a worker that has, you get an unhandled exception from <code>$mdb-&gt;selectDB('collection_name');<\/code> because catch does not run.<\/p>\n<p>When PHP is a single process, i.e. via Apache with mod_php, this behavior does not occur. Just for posterity, going back to Apache\/mod_php is not an option for us at this time.<\/p>\n<p>Is there a way to fix this behavior? I don&#8217;t want the connection state to be inconsistent between different php-fpm processes.<\/p>\n<p><strong>Edit:<\/strong> While I wait for the driver to be fixed in this regard, my current workaround is to do a quick polling to determine if the driver can handle requests and then load or not load the MongoDB library\/run queries if it can&#8217;t connect\/query:<\/p>\n<pre><code>try\n{\n    \/\/ connect\n    $mongo = new Mongo(\"mongodb:\/\/localhost:27017\");\n\n    \/\/ try to do anything with connection handle\n    try\n    {\n        $mongo-&gt;YOUR_DB-&gt;YOUR_COLLECTION-&gt;findOne();\n        $mongo-&gt;close();\n        define('MONGO_STATE', TRUE);\n    }\n    catch(MongoCursorException $e)\n    {\n        $mongo-&gt;close();\n        error_log('Error connecting to MongoDB: ' . $e-&gt;getMessage() );\n        define('MONGO_STATE', FALSE);\n    }\n}\ncatch(MongoConnectionException $e)\n{\n    error_log('Error connecting to MongoDB: ' . $e-&gt;getMessage() );\n    define('MONGO_STATE', FALSE);\n}\n<\/code><\/pre>\n<p id=\"rop\"><small>Originally posted 2013-12-06 14:33:30. <\/small><\/p>","protected":false},"excerpt":{"rendered":"<p>For the relevant part of our server stack, we&#8217;re running: NGINX 1.2.3 PHP-FPM 5.3.10 with PECL mongo 1.2.12 MongoDB 2.0.7 CentOS 6.2 We&#8217;re getting some strange, but predictable behavior when the MongoDB server goes away (crashes, gets killed, etc). Even with a try\/catch block around the connection code, i.e: try { $mdb = new Mongo(&#8216;mongodb:\/\/localhost:27017&#8217;); [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1971","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/1971","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/comments?post=1971"}],"version-history":[{"count":0,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/1971\/revisions"}],"wp:attachment":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/media?parent=1971"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/categories?post=1971"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/tags?post=1971"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}