Graham, Thanks. I didn't think that there would be an issue, but thought I'd cover my bases.
And, no, we do clear the thread local variable (to None) in the response middleware. (And every request that makes it very far into the request middleware stack is supposed to have it reset.) Our symptom looks like it came in with a None value (should not happen). There are request.META variables that are supposed to be set earlier by a SiteMinder Apache plug in, which are used to calculate the thread local variable. I'll have to look there next. Bill On Mon, Mar 31, 2014 at 8:51 PM, Graham Dumpleton < [email protected]> wrote: > There are no known issues. > > Do be aware that mod_wsgi does nothing to clear out thread local data at > the end of a request. Any thread local data set from one request will if > not cleared by your code at the end of the request will still be present > when that same request thread is used to handle a subsequent request. > > Is the issue therefore perhaps that the data is not being clear and on a > subsequent request it isn't reinitialising the thread local data and so > picking up a value from a prior request. > > Graham > > On 01/04/2014, at 5:32 AM, Bill Freeman <[email protected]> wrote: > > I'm wondering if there are any known issues with thread local storage when > running with: > > > WSGIApplicationGroup %{GLOBAL} > > The players: > > Python 2.7.3 > > Apache 2.2.15 > > Modwsgi 3.3 > > Pymongo 2.2 > > Django 1.4 > > A bunch of other hopefully irrelevant stuff > > Code of our own that uses: > > XXX = threading.local() > > And in a django request middleware: > > XXX.yyy = value_computed_from_request > > And down in the views XXX.yyy is used. > > Backstory: > > We were getting exceptions that led (via a URL in the exception > message) to the idea that pymongo doesn't play well with multiple > sub-interpreters. Following recommendations at pymongo's URL, we added: > > WSGIApplicationGroup %{GLOBAL} > > (and supposedly made sure that only one application was running in the > daemon process group, I still have to check this myself. (I wonder if > there's a newrelic modwsgi tool that gives this kind of insight?)) > > But then we get errors that we are currently interpreting as the thread > local variable being wrong. > > We are exploring other possibilities, but it seemed worth asking whether > there are known issues in this combination. > > Thanks, Bill > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
