Uncaught exception 'MongoCursorException' with message 'couldn't send query: ' from PHP

[Mark Bixby]

    I'm sporadically getting this error on our development environment from PHP code:

        Uncaught exception 'MongoCursorException' with message 'couldn't send query: '

   We're running Mongo 2.02 on FreeBSD 9.0 with PHP driver version 1.2.10 and we're using persistent connections ('persist' => 'dev').  I'll generally get this exception several times in a row and then it will clear up.

   Any ideas?

[Mark Bixby]

  
   Also, MongoDB does not show any any errors or warnings so I think this is coming from the PHP driver.

[Derick Rethans]

On Tue, 24 Apr 2012, Mark Bixby wrote:

>
>
> I'm sporadically getting this error on our development environment from
> PHP code:
>

> *Uncaught exception 'MongoCursorException' with message 'couldn't
> send query: ' *

>
> We're running Mongo 2.02 on FreeBSD 9.0 with PHP driver version 1.2.10
> and we're using persistent connections ('persist' => 'dev'). I'll
> generally get this exception several times in a row and then it will clear
> up.

What is this code doing? Are you making forks in PHP? Please also note
that you are always using persistent connections as the driver doesn't
allow anything else (since 1.2)

cheers,
Derick

--
http://mongodb.org | http://derickrethans.nl
twitter: @derickr and @mongodb

[Mark Bixby]

 
   The code is really simple - it's just doing a findOne query on the shard key.

  $cursor = $customer_collection->findOne(
      array("EmailAddress" => $emailaddress),
      $return_cols
  );

[Mark Bixby]

  Also, we're using php-fpm.

[Mark Bixby]

  One last note - we're using PHP Version 5.3.10

[Derick Rethans]

On Tue, 24 Apr 2012, Mark Bixby wrote:

> On Tuesday, April 24, 2012 11:33:16 AM UTC-4, Mark Bixby wrote:
> >
> > On Tuesday, April 24, 2012 11:23:41 AM UTC-4, Mark Bixby wrote:
> >>
> >> On Tuesday, April 24, 2012 9:48:34 AM UTC-4, Derick Rethans wrote:
> >>>
> >>> On Tue, 24 Apr 2012, Mark Bixby wrote:
> >>>
> >>> > I'm sporadically getting this error on our development
> >>> > environment from PHP code:
> >>> >
> >>> > *Uncaught exception 'MongoCursorException' with message 'couldn't send query: ' *
> >>> >
> >>> > We're running Mongo 2.02 on FreeBSD 9.0 with PHP driver version
> >>> > 1.2.10 and we're using persistent connections ('persist' =>
> >>> > 'dev'). I'll generally get this exception several times in a
> >>> > row and then it will clear up.
> >>>
> >>> What is this code doing? Are you making forks in PHP? Please also
> >>> note that you are always using persistent connections as the
> >>> driver doesn't allow anything else (since 1.2)
> >>
> >> The code is really simple - it's just doing a findOne query on the
> >> shard key.
> >>
> >> $cursor = $customer_collection->findOne(
> >> array("EmailAddress" => $emailaddress),
> >> $return_cols
> >> );
> >

> > Also, we're using php-fpm.
>

> One last note - we're using PHP Version 5.3.10

I'm at a loss here, and I think we need to move this to the issue
tracker. Now, the biggest thing is that I need to be able to reproduce
this. Can you reproduce this in a development environment as well? Can
you file an issue at http://jira.mongodb.org so that we can adequately
track it?

[Enrico Kern]

I have the same problem with php and mongo on freebsd. Moved my
Database from a linux mongo to a freebsd system. Compiled mongodb from
the sources. Now i also get query errors that never happened before
for a simple find query.

Uncaught exception 'MongoCursorException' with message 'couldn't send
query:

We run php-cgi with spawn-cgi. What helps is to restart the php-cgi
processes, so i guess the driver got problems here :/ php driver is
1.2.6

[Mark Bixby]

   Here's the JIRA ticket:  https://jira.mongodb.org/browse/PHP-377 

   I can reproduce this in my development environment.  It will mostly happen after I haven't queried Mongo from PHP for a while.  After several tries it will generally work again.

[Ben Ramsey]

I'm noticing the same problem, but I have more details about what might be causing it. The problem seems to happen when I do a new pull down from a repository into a directory that's serving files through a web server. Requests through the web server then start intermittently triggering this error. After restarting Apache, the problem seems to go away. In my case, I'm using APC and, even though apc.stat is set to 1, I wonder if some opcodes are still being held onto, which is causing this problem.

-Ben

[Timothy Hawkins]

Are you using persistent connection pooling? 

It could be that the pool is getting fried when the code is updated or the server is idle for a while, what is the mechanism used to persist the connections?. 

Sent from my iPad

--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com
To unsubscribe from this group, send email to
mongodb-user...@googlegroups.com
See also the IRC channel -- freenode.net#mongodb

[Ben Ramsey]

If I am, it's not because I set it explicitly. I'm using the latest version of the PHP pecl/mongo client. I think Derick said it does persistent connections by default.

-Ben

[Timothy Hawkins]

If php is trying to write to connections that the server has closed, you would get this error, thats why i was asking about the pooling. 

I must admit we dont use any php driver greater than 1.1.4 in production, because everything went to hell for us after that, we could not get the slaveOK mode of querying to work after that version, so we could not distribute load across our replica set.  so we don't have persistent pools.  I spent two days regressing back through php driver versions until our app stopped dieing. 

Running this site: http://www.jcwhitney.com. Hybrid mongo/mysql setup. 

Sent from my iPad

[Ben Ramsey]

That's good to know. We'll be turning on slaveOkay on a replica set soon, so I'll see if the driver gives us the same trouble.

Thanks,

Ben

[Derick Rethans]

On Wed, 16 May 2012, Ben Ramsey wrote:

> I'm noticing the same problem, but I have more details about what might be
> causing it. The problem seems to happen when I do a new pull down from a
> repository into a directory that's serving files through a web server.
> Requests through the web server then start intermittently triggering this
> error. After restarting Apache, the problem seems to go away. In my case,
> I'm using APC and, even though apc.stat is set to 1, I wonder if some
> opcodes are still being held onto, which is causing this problem.

That seems very unlikely. If opcodes go wrong, they go wrong for a whole
function. It hardly even comes near the connections in the Mongo
extension.

[Derick Rethans]

On Thu, 17 May 2012, Timothy Hawkins wrote:

> I must admit we dont use any php driver greater than 1.1.4 in
> production, because everything went to hell for us after that, we
> could not get the slaveOK mode of querying to work after that version,
> so we could not distribute load across our replica set. so we don't
> have persistent pools. I spent two days regressing back through php
> driver versions until our app stopped dieing.

Hmm, yes. The 1.2 series has issues with connections to replicasets etc.
I'm working on rectifying this, but it's a bit of a long process. So
stay tuned!

[Timothy Hawkins]

What sort of timescale are you looking at, because as stated before we are locked out of all the fixes in the 1.2 drivers and greater.

Sent from my iPad

[Michael]

Just adding a  "me too" here, except that it occurs for me when doing a 

$collection->group(....) call.

PHP 5.3.10, driver 1.2.10, Ubuntu 11.10

[Adam C]

FYI to everyone on this thread - this should be fixed in the driver after 1.3.0RC2 (released November 13th) - if anyone seeing this error can test and report if they see it with that version (or later), that would be appreciated.

Adam