ImportError: No module named threading

[Gnarlodious]

My webapp runs normally as a python script, but cannot import module "threading" when run under mod_wsgi. This problem started after I upgraded to Python 3.2.3 which evidently no longer allows concurrent connections to my SQLite database. Suddenly my module crashed with error:
ProgrammingError: SQLite objects created in a thread can only be used in that same thread.The object was created in thread id * and this is thread id *

This is a disaster because the only way to recover is to restart Apache, surely a Python failing that needs to be fixed.

I attempted to isolate sqlite3 objects with this method:

import threading
self.local = threading.local() # Thread local storage for db handles

but I am not sure this is the right solution.

This is OSX 10.8 Server.app running mod_wsgi 3.4 under directive:

WSGIDaemonProcess Sectrum python-path=[path] processes=1 threads=1 display-name=Sectrum

I do have another simpler wsgi script that imports threading without complaining, so I suspect the configuration in the previous line overrides the default and whacks my webapp. Can anyone explain this? And if possible a solution to the sqlite3 concurrency problem?

-- Gnarlie

[Graham Dumpleton]

I would suspect the OS X Server.app mod_wsgi is compiled for Python
2.7 and not Python 3.2. You can't force that mod_wsgi.so to use Python
3.2, you would need to recompile mod_wsgi from source code against
Python 3.2 if you wanted to use Python 3.2.

Which Python version are you wanting to use and what other mod_wsgi
configuration directives have you set in the Apache configuration?

Have you use WSGIPythonHome, WSGIPythonPath or python-path options to
WSGIDaemonProcess or otherwise tried to override where mod_wsgi gets
it Python modules from?

Graham

> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/modwsgi/-/wirjTAO-PFkJ.
> To post to this group, send email to mod...@googlegroups.com.
> To unsubscribe from this group, send email to
> modwsgi+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/modwsgi?hl=en.

[Gnarlodious]

Default 10.8 Server.app invokes mod_wsgi at:

/Applications/Server.app/Contents/ServerRoot/usr/libexec/apache2/mod_wsgi.so

however mine is invoked like:

LoadModule wsgi_module /usr/local/apache2/modules/mod_wsgi.so

NOTE that the OSX updater overwrites the folder at /usr/libexec/apache2/ so don't put your custom stuff there!

The mod_wsgi is compiled using directive:

--enable-framework=/usr/local/python-3.2.3/frameworks/Python.framework/Versions/3.2

The "threading" module is located at the same place as other modules that all work as expected:

/usr/local/python-3.2.3/frameworks/Python.framework/Versions/3.2/lib/python3.2/threading.py

Is there some diagnostic I can plug in to get mod_wsgi to report why it can't import threading? Like I said, I was able to import threading in the Server.app default wsgi webapp with no problem, so it must be my daemon config. I will experiment with other setting and see what happens.

Otherwise, if there were a way to get around the sqlite3 problem I would that solution. Maybe I should ask on the Python board.

-- Gnarlie

[Graham Dumpleton]

On 29 October 2012 13:15, Gnarlodious <gnarl...@gmail.com> wrote:
> Default 10.8 Server.app invokes mod_wsgi at:
>
> /Applications/Server.app/Contents/ServerRoot/usr/libexec/apache2/mod_wsgi.so
>
>
> however mine is invoked like:
>
> LoadModule wsgi_module /usr/local/apache2/modules/mod_wsgi.so
>
>
> NOTE that the OSX updater overwrites the folder at /usr/libexec/apache2/ so
> don't put your custom stuff there!
> The mod_wsgi is compiled using directive:
>
> --enable-framework=/usr/local/python-3.2.3/frameworks/Python.framework/Versions/3.2

The configure script for mod_wsgi doesn't accept any such option.

You should be using --with-python to specify the path to the python3.2
executable.

It is possible that you may have to also supply the
--disable-framework option to configure script to workaround a problem
that comes up for some people whereby it doesn't correctly compile in
the right Python framework to use.

As per:

http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library

use 'otool -L' on .libs/mod_wsgi.so after running make to determine
what Python framework it is picking up.

Post the results of that.

Graham

> https://groups.google.com/d/msg/modwsgi/-/N4BkKm5iJxwJ.

[Gnarlodious]

Solved: 

I removed processes=1 threads=1 from my config and the threading module imports normally. You may want to keep that in mind for future reference.

The sqlite3 concurrency problem remains, however… but only in mod_wsgi. I get error:

AttributeError: '_thread._local' object has no attribute 'ramDB'

Will study that tomorrow.

-- Gnarlie

[Graham Dumpleton]

That is the wrong solution and should have made no difference.

More likely it went away because you stopped and started Apache.

When changing Apache modules doing just a 'restart' doesn't always work.

Please do what I asked you to do with otool -L and post the results
and also ensure you are doing a complete stop and start of Apache when
you are installing a new module, especially one which may be using a
different Python version.

Graham

> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/modwsgi/-/PC_iEt4nOyYJ.

[Gnarlodious]

It seems to be working now after restarting Apache using:

sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist

sudo launchctl load -w /System/Library/LaunchDaemons/org.apache.httpd.plist

This restarts the parent process of the Apache instance Server.app uses. Because I built my own Apache, "launchctl" doesn't work.

When Apache starts it reports:

Apache/2.2.22 (Unix) mod_wsgi/3.4 Python/3.2.3

To answer your question:

otool -L /usr/local/apache2/modules/mod_wsgi.so

/usr/local/apache2/modules/mod_wsgi.so:

/usr/local/python-3.2.3/frameworks/Python.framework/Versions/3.2/Python (compatibility version 3.2.0, current version 3.2.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.1.0)

So I am going to assume this import failure occured because I only restarted the Apache instance Server.app uses and not its parent process.

-- Gnarlie

[Gnarlodious]

OK here is the final report. "import threading" MUST be declared in your *.wsgi script. If not, you get an error "ImportError: No module named threading" from any module importing threading. I don't know why this is the case because it was determined by trial and error.

Anything else I said about this problem was irrelevant.

-- Gnarlie

http://Gnarlodious.com

[Graham Dumpleton]

You aren't playing around with sys.path in the WSGI script file and
mucking up what was in it to begin with?

Try adding in debug which prints out sys.path in WSGI script file and
then later where import of threading was failing.

Graham

> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/modwsgi/-/ZMiikafI2yQJ.

[Gnarlodious]

The two paths are identical at the *.wsgi script and also at the *.py script that crashes.

-- Gnarlie

[Graham Dumpleton]

Did you ever sort out why this was happening?

Graham

> https://groups.google.com/d/msg/modwsgi/-/p3iwVAyksHUJ.

[Gnarlodious]

No. I disabled the offending modules all of which use sqlite3, but it means my webapp is running in a degraded mode. I am waiting for someone else to have this problem and solve it since I am not so knowledgeable.

I did solve the sqlite3 problem by isolating the connection using:
self.local=threading.local()

however every once in a while a new thread is created that doesn't know about the existing connection object, and the webapp crashes despite having fixed the problem.

But even in the degraded mode, my webapp periodically (maybe every few days) resets all its values and creates a new thread (or process, I am in the dark what is happening). This seems to happen in WSGI but not in the interactive mode. One explanation I have cooked up is that Python 3.2.3 runs in its own internal multithreaded mode that mod_wsgi has no control over, and that is the new default we need to deal with. On the other hand, it could be a Python bug.

My server box which is running older software runs the same webapp with no problem.

-- Gnarlie

[Gnarlodious]

I've verified that my webapp is in fact running more than one thread when it is configured to run only one thread. It periodically displays an entire different data set dependng on which thread decides to answer the request. It also explains the problem with objects not being found. But why all this is happening I don't know.

-- Gnarlie

[Gnarlodious]

UPDATE! Some of these complaints may have been solved by rebooting. Upon investigating this phenomenon, the OSX 10.8 (Mountain Lion) Server.app does NOT in fact restart Apache.

It turns out that Server.app is built on top of a subsystem that runs httpd as root user. As a security precaution, it forks off a clone of this root httpd process that uses user _www. When you use the Server.app GUI button to "Stop" and "Start" the web service, you are restarting the Apache's _www process NOT the root process that loads the mod_wsgi configuration This also applies to the Terminal commands:

sudo serveradmin stop web

sudo serveradmin start web

To REALLY restart the Apache parent process and reload the WSGI configuration, you have to use the commands:

sudo launchctl unload /System/Library/LaunchDaemons/org.apache.httpd.plist

sudo launchctl load /System/Library/LaunchDaemons/org.apache.httpd.plist

which is the equivalent of rebooting.

I should explain that my installation is NOT the default Server.app mod_wsgi setup but rather the custom built daemon mode module. The built in WSGI webapp configuration may have a different behavior, I am not sure.

In any case, the original problems still remain, which is that certain objects forget what they are supposed to do:

AttributeError: '_thread._local' object has no attribute 'ramDB'

IMy guess is that under Python 3.2.3 threading must be explicitly declared all the way down.

-- Gnarlie

[Gnarlodious]

I think I've figured out why this was happening. If Server.app can't parse a configuration file when it starts up, it replaces the unreadable file with a default file while leaving Apache running on its previous config. When that happens, restarting the web service causes the new default setting to take effect even though days might have passed since you opened Server.app. I would call it a bug.

This is all very confusing, but the reason for it is that Apple's vision for Apache is to eventually have all configuration files in *.plist format. The shift from *.conf to plist has been gradual and at this time is a combination of both filetypes. I still don't fully understand how it all works and anything I said in previous posts should be taken as guesswork.

My webapp has been running normally for about 24 hours, so I assume the problem is fixed. So it turns out to NOT be a Python or WSGI problem. Thank you for your patience, hopefully my experimenting is helpful to someone.

-- Gnarlie

http://Gnarlodious.com

[Graham Dumpleton]

Interesting. I am hoping soon to upgrade a mac mini at home used as a media server to latest MacOSX and add server extensions, so may finally be able to dig into what message Apple has created.

Graham

--

You received this message because you are subscribed to the Google Groups "modwsgi" group.

To view this discussion on the web visit https://groups.google.com/d/msg/modwsgi/-/sxaoxFTKaL4J.

[Gnarlodious]

Just an update on this problem, I've discovered it also occurs with the pydoc module. I get "ImportError: No module named 'pydoc'" in error.log. It was a simple fix to import the module in the *.wsgi script, and suddenly the Python script found it normally.

-- Gnarlie