pymongo 2.2 leaves open connections

[JJO]

We upgraded to pymongo 2.2, and we are noticing that the number of
open TCP connections to mongo grows over time to exceed the available
file descriptors given to apache. Django then throws odd errors about
templates not readable, urandom not found, etc., that don't happen
before the number of file descriptors is saturated. Downgrading to
pymongo 2.1.1 addressed the problem.

I would appreciate some ideas for next steps.

Ubuntu 10.04.4 LTS (
Apache 2.2 prefork
Python 2.6.5
mod_wsgi 2.8
)
Mongo 2.0.4, single-server configuration (no shards, no replica sets)
pymongo 2.2

[Bernie Hackett]

Can you tell me how your client deals with connections in threads? Do
you call Connection.end_request before a thread dies? We reworked the
connection pooling in 2.2 to address orphaned connections but there
could be a bug.

> --
> 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.
> For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.
>

[JJO]

We never explicitly call end_request. We let our code be agnostic about threads and don't pay much attention. We don't keep shared resources in memory between requests. Because we're running in Apache, we have no idea if requests come in on the same thread or not.

I can tell you this: We have a poller set up from the client web browser, and as the poller makes requests, we can watch the number of connections increase.

WSGI settings might be in order. We have the WSGI settings below defined per VirtualHost, with <myapp> different for each VirtualHost. We have two copies of this python application on this server, and not much else.

        WSGIDaemonProcess <myapp>

        WSGIProcessGroup <myapp>

        WSGIApplicationGroup %{GLOBAL}

[A. Jesse Jiryu Davis]

JJO, if you wouldn't mind posting here or emailing me personally (je...@10gen.com) your apache and wsgi config and a python program that reproduces this error, I'll investigate.

Thanks,

Jesse

[A. Jesse Jiryu Davis]

I've repro'ed this with PyMongo 2.2, Apache 2.2.14, and mod_wsgi 2.8, whereas Apache 2.2.16 and mod_wsgi 3.2 do *not* exhibit this behavior. I suspect that this change to mod_wsgi is related:

https://groups.google.com/d/topic/modwsgi/sIs91L9XVgs/discussion

mod_wsgi 2.x treats thread locals very strangely and PyMongo 2.2 isn't handling this strangeness. I'm going to investigate further so we can support mod_wsgi 2.x. In the meantime you can upgrade mod_wsgi to 3.2 to fix the connection-growth, and get PyMongo 2.2's other benefits.

[A. Jesse Jiryu Davis]

We're starting to understand this issue but it's a bit subtle. Options to fix it:

*) using PyMongo 2.2, set auto_start_request=False

*) remain on PyMongo 2.1.1

*) upgrade mod_wsgi to 3.2

*) upgrade Python to 2.7 (this requires recompiling mod_wsgi, so at this point it seems like you might as well upgrade mod_wsgi anyway)

[A. Jesse Jiryu Davis]

Sorry for the delay -- fully understanding this bug has been epic. See https://jira.mongodb.org/browse/PYTHON-353 . For now, the four possible workarounds I posted previously are still valid. We plan to release a bugfix shortly.

[A. Jesse Jiryu Davis]

And finally, we've released PyMongo 2.2.1 with a fix that will work for all versions of mod_wsgi and Python.

http://pypi.python.org/pypi/pymongo/