mongodb connection-bug

[badxpgy]

$manager = new MongoDB\Driver\Manager("mongodb://192.168.1.11:5000,192.168.1.22:5000", array(
        'connect' => true,
        'connectTimeoutMS' => 1000,
        'socketTimeoutMS' => 5000,
        'replicaSet'=>"pktest"
    ));
    $options['projection'] = array();
    $options['limit'] = 1;
    $query = new MongoDB\Driver\Query(array('_id' => 21), $options);
    $rp = new MongoDB\Driver\ReadPreference(MongoDB\Driver\ReadPreference::RP_PRIMARY);
    $result = $manager->executeQuery("test.test", $query, $rp);
    var_dump($result);

When the first IP port(192.168.1.11:5000) is the PRIMARY and existing, But the last IP port(192.168.1.22:5000) does not exist, Run time prompt (No suitable servers found (serverselectiontryonce set): [connection error calling ismaster on).

If the two IP for a location, and normal, （"mongodb://192.168.1.22:5000,192.168.1.11:5000"）

PHP5.4-7.0.4/mongodb1.1.3-1.1.5 Have this problem.

[jmikola]

When the first IP port(192.168.1.11:5000) is the PRIMARY and existing, But the last IP port(192.168.1.22:5000) does not exist, Run time prompt (No suitable servers found (serverselectiontryonce set): [connection error calling ismaster on).

Are you sure that you copied the entire exception? That exception message looks cut off.

If I understand this correctly, the first host in the connection URI is accessible and happens to be the replica set primary, and the second host is inaccessible. In this case, the driver is going to block for the duration of the connection timeout. This will either be the "connectTimeoutMS" URI option, if set, or the generic default_socket_timeout PHP INI option.

Consider the following example, where I'm connecting to a local replica set with an inaccessible second node in my URI:

[2016-04-04T23:55:03+00:00]     PHONGO: TRACE   > ENTRY: phongo_stream_initiator():1170
[2016-04-04T23:55:03+00:00]     PHONGO: DEBUG   > Connecting to '192.168.112.10:3000[mongodb://192.168.112.10:3000,128.0.0.1:1234]'
[2016-04-04T23:55:03+00:00]     PHONGO: DEBUG   > Created: RSRC#5 as '192.168.112.10:3000[mongodb://192.168.112.10:3000,128.0.0.1:1234]'
[2016-04-04T23:55:03+00:00]     PHONGO: TRACE   >  EXIT: phongo_stream_initiator():1295
[2016-04-04T23:55:03+00:00]     PHONGO: TRACE   > ENTRY: phongo_stream_initiator():1170
[2016-04-04T23:55:03+00:00]     PHONGO: DEBUG   > Connecting to '128.0.0.1:1234[mongodb://192.168.112.10:3000,128.0.0.1:1234]'
[2016-04-04T23:56:03+00:00]     PHONGO: TRACE   >  EXIT: phongo_stream_initiator():1220

In this case, the driver immediately connects to the first server but blocks for a full minute (relying on default_socket_timeout in this case, which is 60 seconds by default) attempting to connect to the second host. If I add ['connecttimeoutms' => 1000] to the Manager options, the same script only blocks for one second. Note that PHPC-655 (to be released in 1.1.6) fixes an issue with case-sensitive parsing of the "connectTimeoutMS" option, which is why I had to use all lowercase characters with 1.1.5.

If you still believe this is incorrect behavior, please follow up with a debug log obtained via the mongodb.debug INI option. For a CLI script, you can simply use "stderr" to dump logs to stderr (of course). From a web SAPI, you can specify a directory and have the driver dump logs for each process to that directory (more convenient than having each request thread write to the same file).

[asp24]

I have the save issue. 4 node RS. Exception message is

No suitable servers found (serverselectiontryonce set): [connection error calling ismaster on '172.20.1.110:27017'] [Failed connecting to 'mongo-02-rs0-nl.local:27017': No route to host]

Trace string: vendor/mongodb/mongodb/src/Collection.php(318): MongoDB\Driver\Manager->selectServer(Object(MongoDB\Driver\ReadPreference))

rs.status()

rs0:PRIMARY> rs.status()
{
    "set" : "rs0",
    "date" : ISODate("2016-04-05T13:01:03.894Z"),
    "myState" : 1,
    "members" : [
        {
            "_id" : 0,
            "name" : "172.20.1.110:27017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 5369506,
            "optime" : Timestamp(1459861263, 1),
            "optimeDate" : ISODate("2016-04-05T13:01:03Z"),
            "electionTime" : Timestamp(1454491940, 1),
            "electionDate" : ISODate("2016-02-03T09:32:20Z"),
            "configVersion" : 7,
            "self" : true
        },
        {
            "_id" : 1,
            "name" : "mongo-02-rs0-nl.local:27017",
            "health" : 0,
            "state" : 8,
            "stateStr" : "(not reachable/healthy)",
            "uptime" : 0,
            "optime" : Timestamp(0, 0),
            "optimeDate" : ISODate("1970-01-01T00:00:00Z"),
            "lastHeartbeat" : ISODate("2016-04-05T13:00:59.551Z"),
            "lastHeartbeatRecv" : ISODate("2016-04-05T12:07:04.234Z"),
            "pingMs" : 0,
            "lastHeartbeatMessage" : "Failed attempt to connect to mongo-02-rs0-nl.local:27017; couldn't connect to server mongo-02-rs0-nl.local:27017 (172.20.1.111), connection attempt failed",
            "configVersion" : -1
        },
        {
            "_id" : 2,
            "name" : "mongo-backup-rs0-nl.local:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 2263393,
            "optime" : Timestamp(1459861262, 921),
            "optimeDate" : ISODate("2016-04-05T13:01:02Z"),
            "lastHeartbeat" : ISODate("2016-04-05T13:01:03.448Z"),
            "lastHeartbeatRecv" : ISODate("2016-04-05T13:01:03.611Z"),
            "pingMs" : 0,
            "syncingTo" : "mongo-03-rs0-nl.local:27017",
            "configVersion" : 7
        },
        {
            "_id" : 3,
            "name" : "mongo-03-rs0-nl.local:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 1033116,
            "optime" : Timestamp(1459861262, 921),
            "optimeDate" : ISODate("2016-04-05T13:01:02Z"),
            "lastHeartbeat" : ISODate("2016-04-05T13:01:03.196Z"),
            "lastHeartbeatRecv" : ISODate("2016-04-05T13:01:03.439Z"),
            "pingMs" : 0,
            "syncingTo" : "172.20.1.110:27017",
            "configVersion" : 7
        }
    ],
    "ok" : 1
}

Connection string is mongodb://mongo-01-rs0-nl.local:27017,mongo-02-rs0-nl.local:27017,mongo-03-rs0-nl.local:27017/?replicaSet=rs0&w=majority&readPreference=nearest&connectTimeoutMS=500

PHP extension setting

mongodb

mongodb support => enabled
mongodb version => 1.1.5
mongodb stability => stable
libmongoc version => 1.3.3
libbson version => 1.3.3

Having deleted unavailable RS node (rs.remove("mongo-02-rs0-nl.local:27017")), the application started to work without any exceptions

[sdotz]

Same issue here in 1.1.6 with php 7.0.4-6. This breaks fault tolerance entirely. I have only found the driver respects the php default socket timeout for selecting a candidate.

[laurentglayal]

For information, I met the same issue using the legacy driver (1.6.12 on PHP 5.3) with mongo servers 2.6.7 running with an arbiter and 4 nodes. Turning off two hosts with mongod processes set the PHP application in unstable state, (turning off the host, not only shutting down the mongod process). When mongod is down the OS can still reject TCP connections, so near immediate answer, when host is down but server is still registered in cluster topology the client tries to connect to hosts and a timeout is raised. It seems connection operations are blocking, even if a PRIMARY and a SECONDARY are available and both are enough to satisfy queries the client still wait from answers from all nodes, even the ones unnecessary and down. I also workaround using rs.remove() then rs.add() when servers are turned on again... quite manual operations for clustering and failure recovery that should be near transparent. In my case the url to connect to replicaset only used the two hosts stayed alive.
TCP connections should be non-blocking, and algorithm detecting issues in cluster should handle such cases.I thougth new driver would fix it but it doesn't seem.
Other applications using nodejs driver seemed to work more softly on such case.

[vingrad]

Please fix this issue.

[mk6i]

+1 Please fix

[vingrad]

This bug is still present. Please open.

[badxpgy]

@vingrad ok

[jmikola]

1.2.0alpha2 has been released, which includes significant changes to our connection handling and persistence. We've entirely dropped PHP's streams API and now rely on libmongoc for all socket communication, which I expect may resolve a number of outstanding connection handling and timeout issues.

@badxpgy: Please attempt reproducing your original problem with 1.2.0alpha2 and let us know if the issue persists. Thanks!