On 8 April 2010 07:43, Michael Schurter <[email protected]> wrote: > On Wed, Apr 7, 2010 at 2:02 PM, Michael Dirolf <[email protected]> wrote: >> As a follow-up, there is a fix that went into PyMongo since 1.5.2 for >> behavior similar to this. I think the OP is looking into this now, but >> unless the master of PyMongo fails (against any version of modwsgi), I >> think that was probably the issue... > > Sorry for the noise. It appears that it was simply a bug in PyMongo > 1.5.2 and a Python path error led me to believe modwsgi was related. > > FWIW, PyMongo master (aka 1.5.2+) works as expected everywhere.
It would be odd that if it was a PyMongo issue that it only affected mod_wsgi 2.X. The only reason I could think for that is that how thread locals are managed in mod_wsgi changed between mod_wsgi 2.X and 3.X. Specifically, in mod_wsgi 2.X the thread local data was only preserved until the end of that request. In mod_wsgi 3.X the thread local data survives between requests using the same external thread from Apache's thread pool. Only problem that could come from this is if PyMongo has a C extension component which was coping properly with being destroyed all the time and would only work where the object persisted for the life of the process. That said, some pure Python WSGI servers don't have persistent thread pools and will destroy/create threads as required. Thus in that situation could also end up with thread local data being destroyed on a regular basis. If you have a reference to the specific bug fix that may have been made that addressed the issue, would be interested to see it. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
