PHP Driver
  1. PHP Driver
  2. PHP-158

Persistent connections: Dropped connections not detected

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major - P3 Major - P3
    • Resolution: Fixed
    • Affects Version/s: 1.0.8
    • Fix Version/s: 1.3.0beta2
    • Component/s: Connection
    • Labels:
      None
    • Environment:
      Apache, CentOS 5, PHP 5.2
    • Operating System:
      ALL
    • # Replies:
      13
    • Last comment by Customer:
      false

      Description

      We use persistent connections which are normally fine, but when a Mongo server is restarted, if we don't also restart Apache we get a bunch of errors about not being able to send the request. It seems like the driver doesn't detect when the connection is lost.

        Issue Links

          Activity

          Hide
          Mike
          added a comment -

          I have the same problem with php-fpm and driver version 1.1.4, the exception message is 'Broken Pipe'. I have to restart the PHP process to fix it.

          Show
          Mike
          added a comment - I have the same problem with php-fpm and driver version 1.1.4, the exception message is 'Broken Pipe'. I have to restart the PHP process to fix it.
          Hide
          Kristina Chodorow (Inactive)
          added a comment -

          To everyone watching this issue:

          I am working on a major rewrite of the connection code to use connection pooling, which should take care of these persistent connection issues. I would really appreciate it if you could try this new code (on a NON-PRODUCTION system) and let me know if it works better for you.

          You can download the latest code from https://github.com/mongodb/mongo-php-driver (should show up as version 1.2.0-).

          You shouldn't need to change any PHP code.

          In the interests of not getting "off-topic," please let me know about general problems with connection pooling at PHP-132. Feel free to comment about problems reconnecting on this bug.

          Show
          Kristina Chodorow (Inactive)
          added a comment - To everyone watching this issue: I am working on a major rewrite of the connection code to use connection pooling, which should take care of these persistent connection issues. I would really appreciate it if you could try this new code (on a NON-PRODUCTION system) and let me know if it works better for you. You can download the latest code from https://github.com/mongodb/mongo-php-driver (should show up as version 1.2.0-). You shouldn't need to change any PHP code. In the interests of not getting "off-topic," please let me know about general problems with connection pooling at PHP-132 . Feel free to comment about problems reconnecting on this bug.
          Hide
          auto
          added a comment -

          Author:

          {u'login': u'kchodorow', u'name': u'Kristina', u'email': u'kristina@10gen.com'}

          Message: fix rs host updates PHP-158
          Branch: master
          https://github.com/mongodb/mongo-php-driver/commit/0dec0d93ac7113a40f3634be858fe669a2d666d8

          Show
          auto
          added a comment - Author: {u'login': u'kchodorow', u'name': u'Kristina', u'email': u'kristina@10gen.com'} Message: fix rs host updates PHP-158 Branch: master https://github.com/mongodb/mongo-php-driver/commit/0dec0d93ac7113a40f3634be858fe669a2d666d8
          Hide
          Mauricio Piacentini
          added a comment -

          Hi. I am seeing this issue (or a similar one) with updated drivers, version 1.2.3, connected to a replicaSet running 1.8.3. I can reproduce it reliably. There are several "game" machines running nginx + php_cgi, connected to my replicaSet. If I go to the primary and issue a rs.stepDown(), or take it offline, then the replicaSet reconfigures itself and elects a new primary. However, php code can no longer query the database: I get the "max number of retries exhausted, couldn't send query" message in my logs that collect the exception, and sometimes a "couldn't get response header" as well. I waited for 10-15 minutes, and some queries never completed. I did a new test, disabling APC in php.ini, just to be sure. Same results. If I restart php-cgi on a given machine, all queries immediately complete, and I never get the error.
          I believe the reason some queries complete without the restart after 10-15 minutes is because php_cgi respawns some of the child processes by itself, but this is difficult to diagnose.
          What I can reproduce reliably is that, after a stepDown, or when mongod is stopped on the primary (simulating a failure), these exceptions pile up for several minutes. Again, restarting php-cgi immediately restores connectivity for one machine (others that are not restarted still can not connect.)
          If there is anything I can try to help you diagnose this, please let me know. Also, if there is a way to "force" the persistent connection (I assume the driver is maintaining one "behind the scenes") to be recycled when I get this exception, this will also help us. Thanks.

          Show
          Mauricio Piacentini
          added a comment - Hi. I am seeing this issue (or a similar one) with updated drivers, version 1.2.3, connected to a replicaSet running 1.8.3. I can reproduce it reliably. There are several "game" machines running nginx + php_cgi, connected to my replicaSet. If I go to the primary and issue a rs.stepDown(), or take it offline, then the replicaSet reconfigures itself and elects a new primary. However, php code can no longer query the database: I get the "max number of retries exhausted, couldn't send query" message in my logs that collect the exception, and sometimes a "couldn't get response header" as well. I waited for 10-15 minutes, and some queries never completed. I did a new test, disabling APC in php.ini, just to be sure. Same results. If I restart php-cgi on a given machine, all queries immediately complete, and I never get the error. I believe the reason some queries complete without the restart after 10-15 minutes is because php_cgi respawns some of the child processes by itself, but this is difficult to diagnose. What I can reproduce reliably is that, after a stepDown, or when mongod is stopped on the primary (simulating a failure), these exceptions pile up for several minutes. Again, restarting php-cgi immediately restores connectivity for one machine (others that are not restarted still can not connect.) If there is anything I can try to help you diagnose this, please let me know. Also, if there is a way to "force" the persistent connection (I assume the driver is maintaining one "behind the scenes") to be recycled when I get this exception, this will also help us. Thanks.
          Hide
          Derick Rethans
          added a comment -

          This should be fixed in the 1.3.0 branch on github, and in both beta1 (released) and the upcoming beta2.

          Show
          Derick Rethans
          added a comment - This should be fixed in the 1.3.0 branch on github, and in both beta1 (released) and the upcoming beta2.

            People

            • Votes:
              9 Vote for this issue
              Watchers:
              16 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since reply:
                1 year, 33 weeks ago
                Date of 1st Reply: