[modwsgi] Re: threading.local
On 06-10-2008, William Dode wrote: On 06-10-2008, William Dode wrote: ... The only problem is that there is not a lot of db pool utilities and dbutils is one of the most famous... I reported the problem on the dbutils list DBUtils 1.0rc1 now works with mod_wsgi :-) -- William Dodé - http://flibuste.net Informaticien Indépendant --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com 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 -~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
On Oct 7, 9:58 am, William Dode [EMAIL PROTECTED] wrote:
On 06-10-2008, gert wrote:
On Oct 6, 11:48 pm, gert [EMAIL PROTECTED] wrote:
Will this share connections between requests ?
import _mysql
db = _mysql.connect('127.0.0.1','root','root','www')
def application(environ, start_response):
db.query(SELECT test FROM test)
row = db.store_result()
v = row.fetch_row()[0][0]
db.close()
response_headers = [('Content-type', 'text/html'),('Content-
Length', str(len(v)))]
start_response('200 OK', response_headers)
return [v]
nope it gives the exact same result, works one time and after the
first request you get
[Tue Oct 07 00:54:22 2008] [error] [client 80.200.212.91] Traceback
(most recent call last):, referer:http://87.98.218.86/
[Tue Oct 07 00:54:22 2008] [error] [client 80.200.212.91] File /srv/
www/gil.py, line 12, in application, referer:http://87.98.218.86/
[Tue Oct 07 00:54:22 2008] [error] [client 80.200.212.91]
db.query(SELECT test FROM test), referer:http://87.98.218.86/
[Tue Oct 07 00:54:22 2008] [error] [client 80.200.212.91]
InterfaceError: (0, ''), referer:http://87.98.218.86/
so can you make modwsgi share global variables between requests ?
It is. In your example db will be shared between requests.
But if you have more than one thread you have to know how to share
theses resources ! Is your connection thread safe ?
Don't forget also that if you share the same db connection between
request you cannot use transaction...
You use _mysql instead of mysql and a query on the connection instead of
the cursor... I don't know what you do !
_mysql is a 50% speed increase on what Graham calls the not again
benchmark script made by me with has a soul purpose to get the number
of request as high as possible ignoring things like security,
reliability, memory, processing you know the benchmark everybody is
interested in :-)
So clearly my db connections are not made to be used globally and as
always before Graham can say for god sake why me i blame Graham for
it.
Your are ride about the START TRANSACTION; not going to work like that
but never the less, I still expect the simple query thing to work and
share the database connection. Note that i use prefork not worker
apache (prefork faster btw using mod_wsgi) So its just memory from a
single process that needs to be available to a other request handled
by the same single threaded process. Unless there is a line in
mode_wsgi that say's if ( group == gert ) { malloc(size_t
i_dont_think_so); } I still think it should work ?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
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
-~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
So will start to figure things out but can i ask a global overall
newbie python wsgi question :)
x = 1
def application(environ, start_response):
status = '200 OK'
global x
x = x + 1
output = str(x)
response_headers = [('Content-type', 'text/html'),('Content-
Length', str(len(output)))]
start_response(status, response_headers)
return [output]
if __main__ == __name__ :
e = ...
r = ...
print application(e,r)
what does e and r need to do some local python testing ?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
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
-~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
Failed requests:9993 But I did have 1564.21 requests per second doh :-) anyway http://87.98.218.86/gil.py seem to work ? http://87.98.218.86/bench.txt (added my apache.conf) http://87.98.218.86/bench.htm So did we find a gil bug in Grahams mighty code ? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com 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 -~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
On Oct 6, 10:18 am, Graham Dumpleton [EMAIL PROTECTED] wrote: 2008/10/6 gert [EMAIL PROTECTED]: Failed requests: 9993 But I did have 1564.21 requests per second doh :-) anywayhttp://87.98.218.86/gil.pyseem to work ? http://87.98.218.86/bench.txt(added my apache.conf) http://87.98.218.86/bench.htm So did we find a gil bug in Grahams mighty code ? No one will never know because you never post enough information. If the script is generating a 500 error response, what was the traceback or other error in the Apache error log? Have you tried to debug what was causing the error? Graham I have alot of this [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] Traceback (most recent cal l last): [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] File /srv/www/ gil.py,line 11, in application [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] db.query(SELECT testFROM test) [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] InterfaceError: (0, '') [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] mod_wsgi (pid=1134): Excep tion occurred processing WSGI script '/srv/www/gil.py'. Cool I noticed that pressing f5 it sometimes works and sometimes doesn't lol :) :) :) when it works i get [Mon Oct 06 10:30:46 2008] [info] [client 80.200.216.121] mod_wsgi (pid=1542, process='', application=''): Loading WSGI script '/srv/www/ gil.py'. When it doesnt i get [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] Traceback (most recent cal l last): [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] File /srv/www/ gil.py,line 11, in application [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] db.query(SELECT testFROM test) [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] InterfaceError: (0, '') [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] mod_wsgi (pid=1134): Excep tion occurred processing WSGI script '/srv/www/gil.py'. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com 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 -~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
On Oct 6, 10:33 am, gert [EMAIL PROTECTED] wrote: On Oct 6, 10:18 am, Graham Dumpleton [EMAIL PROTECTED] wrote: 2008/10/6 gert [EMAIL PROTECTED]: Failed requests: 9993 But I did have 1564.21 requests per second doh :-) anywayhttp://87.98.218.86/gil.pyseemto work ? http://87.98.218.86/bench.txt(addedmy apache.conf) http://87.98.218.86/bench.htm So did we find a gil bug in Grahams mighty code ? No one will never know because you never post enough information. If the script is generating a 500 error response, what was the traceback or other error in the Apache error log? Have you tried to debug what was causing the error? Graham I have alot of this [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] Traceback (most recent cal l last): [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] File /srv/www/ gil.py, line 11, in application [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] db.query(SELECT test FROM test) [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] InterfaceError: (0, '') [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] mod_wsgi (pid=1134): Excep tion occurred processing WSGI script '/srv/www/gil.py'. Cool I noticed that pressing f5 it sometimes works and sometimes doesn't lol :) :) :) when it works i get [Mon Oct 06 10:30:46 2008] [info] [client 80.200.216.121] mod_wsgi (pid=1542, process='', application=''): Loading WSGI script '/srv/www/ gil.py'. When it doesnt i get [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] Traceback (most recent cal l last): [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] File /srv/www/ gil.py, line 11, in application [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] db.query(SELECT test FROM test) [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] InterfaceError: (0, '') [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] mod_wsgi (pid=1134): Excep tion occurred processing WSGI script '/srv/www/gil.py'. This is what i get in gdb with cflag -g in make file Starting program: /usr/sbin/apache2 -X (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type return to continue, or q return to quit--- (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread 0x7f304cb12760 (LWP 6503)] (no debugging symbols found) (no debugging symbols found) It seems that gil.py will work one time and then stops working until you reloading the WSGI script --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com 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 -~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
On 06-10-2008, gert wrote: On Oct 6, 10:33 am, gert [EMAIL PROTECTED] wrote: On Oct 6, 10:18 am, Graham Dumpleton [EMAIL PROTECTED] wrote: 2008/10/6 gert [EMAIL PROTECTED]: Failed requests: 9993 But I did have 1564.21 requests per second doh :-) anywayhttp://87.98.218.86/gil.pyseemto work ? http://87.98.218.86/bench.txt(addedmy apache.conf) http://87.98.218.86/bench.htm So did we find a gil bug in Grahams mighty code ? No one will never know because you never post enough information. If the script is generating a 500 error response, what was the traceback or other error in the Apache error log? Have you tried to debug what was causing the error? Graham I have alot of this [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] Traceback (most recent cal l last): [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] File /srv/www/ gil.py, line 11, in application [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] db.query(SELECT test FROM test) [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] InterfaceError: (0, '') You have an InterfaceError, then, look also at the log of your database server... Did you loose the connection ? Did you share a not thread safe connection ? -- William Dodé - http://flibuste.net Informaticien Indépendant --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com 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 -~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
On 06-10-2008, William Dode wrote: ... The only problem is that there is not a lot of db pool utilities and dbutils is one of the most famous... I reported the problem on the dbutils list -- William Dodé - http://flibuste.net Informaticien Indépendant --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com 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 -~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
On 04-10-2008, Graham Dumpleton wrote:
BTW, if I am right, you would see the behaviour you expect to see if you use:
WSGIApplicationGroup %{GLOBAL}
More or less, it give me alternatively two differents local instances...
But i'm agree with your analyze, that to use threading.local is not
reliable. It's ok to keep the connection for the time of the request but
not for a persistent pool between requests. It's just to know about it.
The only problem is that there is not a lot of db pool utilities and
dbutils is one of the most famous...
--
William Dodé - http://flibuste.net
Informaticien Indépendant
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
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
-~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
Will this share connections between requests ?
import _mysql
db = _mysql.connect('127.0.0.1','root','root','www')
def application(environ, start_response):
db.query(SELECT test FROM test)
row = db.store_result()
v = row.fetch_row()[0][0]
db.close()
response_headers = [('Content-type', 'text/html'),('Content-
Length', str(len(v)))]
start_response('200 OK', response_headers)
return [v]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
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
-~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
On Oct 6, 11:48 pm, gert [EMAIL PROTECTED] wrote:
Will this share connections between requests ?
import _mysql
db = _mysql.connect('127.0.0.1','root','root','www')
def application(environ, start_response):
db.query(SELECT test FROM test)
row = db.store_result()
v = row.fetch_row()[0][0]
db.close()
response_headers = [('Content-type', 'text/html'),('Content-
Length', str(len(v)))]
start_response('200 OK', response_headers)
return [v]
nope it gives the exact same result, works one time and after the
first request you get
[Tue Oct 07 00:54:22 2008] [error] [client 80.200.212.91] Traceback
(most recent call last):, referer: http://87.98.218.86/
[Tue Oct 07 00:54:22 2008] [error] [client 80.200.212.91] File /srv/
www/gil.py, line 12, in application, referer: http://87.98.218.86/
[Tue Oct 07 00:54:22 2008] [error] [client 80.200.212.91]
db.query(SELECT test FROM test), referer: http://87.98.218.86/
[Tue Oct 07 00:54:22 2008] [error] [client 80.200.212.91]
InterfaceError: (0, ''), referer: http://87.98.218.86/
so can you make modwsgi share global variables between requests ?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
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
-~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
2008/10/6 gert [EMAIL PROTECTED]: On Oct 6, 10:33 am, gert [EMAIL PROTECTED] wrote: On Oct 6, 10:18 am, Graham Dumpleton [EMAIL PROTECTED] wrote: 2008/10/6 gert [EMAIL PROTECTED]: Failed requests:9993 But I did have 1564.21 requests per second doh :-) anywayhttp://87.98.218.86/gil.pyseemto work ? http://87.98.218.86/bench.txt(addedmy apache.conf) http://87.98.218.86/bench.htm So did we find a gil bug in Grahams mighty code ? No one will never know because you never post enough information. If the script is generating a 500 error response, what was the traceback or other error in the Apache error log? Have you tried to debug what was causing the error? Graham I have alot of this [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] Traceback (most recent cal l last): [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] File /srv/www/ gil.py,line 11, in application [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] db.query(SELECT testFROM test) [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] InterfaceError: (0, '') [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] mod_wsgi (pid=1134): Excep tion occurred processing WSGI script '/srv/www/gil.py'. Cool I noticed that pressing f5 it sometimes works and sometimes doesn't lol :) :) :) when it works i get [Mon Oct 06 10:30:46 2008] [info] [client 80.200.216.121] mod_wsgi (pid=1542, process='', application=''): Loading WSGI script '/srv/www/ gil.py'. When it doesnt i get [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] Traceback (most recent cal l last): [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] File /srv/www/ gil.py,line 11, in application [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] db.query(SELECT testFROM test) [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] InterfaceError: (0, '') [Mon Oct 06 09:56:02 2008] [error] [client 127.0.0.1] mod_wsgi (pid=1134): Excep tion occurred processing WSGI script '/srv/www/gil.py'. This is what i get in gdb with cflag -g in make file Which says absolutely nothing. Just because I suggested to someone else that gdb could be used to debug an issue, doesn't mean it is then a magic bullet that is applicable to every situation. It will only be of use it quite specific situations. I sincerely hope that the debug suggestions you give to people will not now expand to, 'replace your whole Apache configuration with yours' and 'run gdb to work out problem'. Both suggestions aren't helpful. :-) Graham Starting program: /usr/sbin/apache2 -X (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type return to continue, or q return to quit--- (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New Thread 0x7f304cb12760 (LWP 6503)] (no debugging symbols found) (no debugging symbols found) It seems that gil.py will work one time and then stops working until you reloading the WSGI script --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com 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 -~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
2008/10/6 gert [EMAIL PROTECTED]:
But how would you launch a mysql connection so i can do
loc = threading.local()
db = loc.db
db.execute(SELECT * FROM Graham,())
when WSGIApplicationGroup %{GLOBAL} is set
At a guess, something like:
import threading
local = threading.local()
def application(.):
try:
db = local.db
except:
db = local.db = stuff to create connection
db.execute(SELECT documentation FROM manual,())
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
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
-~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
dammit threading sucks :( http://87.98.218.86/bench.txt http://87.98.218.86/bench.htm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com 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 -~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
That is because you didn't read the example properly. The
threading.local() instance is meant to be at global scope in module.
# Global !!!
local = threading.local()
def application(environ, start_response):
try:
db = local.db
except:
local.db = _mysql.connect('127.0.0.1','root','root','www')
db = local.db
Graham
2008/10/6 gert [EMAIL PROTECTED]:
it works can't wait to benchmark it :)
http://code.google.com/p/appwsgi/source/browse/trunk/www/lib/db.py
aldo i don't know if it really really works.
also i think the __del__ methode actually deletes it anyway every
request ?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
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
-~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
But how would you launch a mysql connection so i can do
loc = threading.local()
db = loc.db
db.execute(SELECT * FROM Graham,())
when WSGIApplicationGroup %{GLOBAL} is set
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
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
-~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
Maybe more clear :
#!/usr/bin/python
import cgi
import threading
import sys
import os
class MyLoc(threading.local):
def __init__(self):
print sys.stderr , 'init'
myloc = MyLoc()
def application(environ, start_response):
status = '200 OK'
myloc.i = 0
print sys.stderr, 'pid: %s id: %s id.__dict__: %s' % (os.getpid(),
id(myloc), id(myloc.__dict__))
output = ''
response_headers = [('Content-type', 'text/html'), ]
start_response(status, response_headers)
return [cgi.escape(output)]
[Fri Oct 03 11:37:04 2008] [error] init
[Fri Oct 03 11:37:04 2008] [error] pid: 1836 id: 3067827220 id.__dict__:
3067884244
[Fri Oct 03 11:37:04 2008] [error] init
[Fri Oct 03 11:37:04 2008] [error] pid: 1836 id: 3067827220 id.__dict__:
3067885740
[Fri Oct 03 11:37:05 2008] [error] init
[Fri Oct 03 11:37:05 2008] [error] pid: 1836 id: 3067827220 id.__dict__:
3067884244
[Fri Oct 03 11:37:05 2008] [error] init
[Fri Oct 03 11:37:05 2008] [error] pid: 1836 id: 3067827220 id.__dict__:
3067885740
init should not be called and __dict__ should not be different
The same with wsgiref :
from wsgiref.simple_server import make_server
make_server('',8080,application).serve_forever()
init
pid: 1868 id: 3082036284 id.__dict__: 3082022260
pid: 1868 id: 3082036284 id.__dict__: 3082022260
pid: 1868 id: 3082036284 id.__dict__: 3082022260
pid: 1868 id: 3082036284 id.__dict__: 3082022260
pid: 1868 id: 3082036284 id.__dict__: 3082022260
I'll look if i can reproduce this with the code of _threading_local
--
William Dodé - http://flibuste.net
Informaticien Indépendant
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
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
-~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
I'll look if i can reproduce this with the code of _threading_local With _threading_local it works (python implementation) import _threading_local class MyLoc(_threading_local.local): [Fri Oct 03 11:47:08 2008] [error] init [Fri Oct 03 11:47:08 2008] [error] pid: 2091 id: 3067888900 id.__dict__: 3067885876 [Fri Oct 03 11:47:08 2008] [error] pid: 2091 id: 3067888900 id.__dict__: 3067885876 [Fri Oct 03 11:47:09 2008] [error] pid: 2091 id: 3067888900 id.__dict__: 3067885876 -- William Dodé - http://flibuste.net Informaticien Indépendant --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com 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 -~--~~~~--~~--~--~---
[modwsgi] Re: threading.local
One possibility is that although you think you are using daemon mode,
you aren't, and that Apache compiled with worker MPM. This can occur
if you don't have WSGIProcessGroup directive set properly to refer to
daemon process group setup using WSGIDaemonProcess.
Post the mod_wsgi bits of the Apache configuration, include any
VirtualHost, Directory, Location context they are defined in.
In your per request debug also print out:
print sys.stderr, environ.get('mod_wsgi.process_group')
print sys.stderr, environ.get('mod_wsgi.application_group')
print sys.stderr, environ.get('wsgi.multithread')
print sys.stderr, environ.get('wsgi.multiprocess')
If mod_wsgi.process_group prints out as empty string, you are running
in embedded mode. If multithread is true shows that running in
multithreaded process and not single threaded process as you expect
and thus also why result may be different each time.
You could also print out:
print sys.stderr, threading.currentThread()
to show what Python thinks the thread is each time.
Graham
2008/10/3 William Dode [EMAIL PROTECTED]:
Maybe more clear :
#!/usr/bin/python
import cgi
import threading
import sys
import os
class MyLoc(threading.local):
def __init__(self):
print sys.stderr , 'init'
myloc = MyLoc()
def application(environ, start_response):
status = '200 OK'
myloc.i = 0
print sys.stderr, 'pid: %s id: %s id.__dict__: %s' % (os.getpid(),
id(myloc), id(myloc.__dict__))
output = ''
response_headers = [('Content-type', 'text/html'), ]
start_response(status, response_headers)
return [cgi.escape(output)]
[Fri Oct 03 11:37:04 2008] [error] init
[Fri Oct 03 11:37:04 2008] [error] pid: 1836 id: 3067827220 id.__dict__:
3067884244
[Fri Oct 03 11:37:04 2008] [error] init
[Fri Oct 03 11:37:04 2008] [error] pid: 1836 id: 3067827220 id.__dict__:
3067885740
[Fri Oct 03 11:37:05 2008] [error] init
[Fri Oct 03 11:37:05 2008] [error] pid: 1836 id: 3067827220 id.__dict__:
3067884244
[Fri Oct 03 11:37:05 2008] [error] init
[Fri Oct 03 11:37:05 2008] [error] pid: 1836 id: 3067827220 id.__dict__:
3067885740
init should not be called and __dict__ should not be different
The same with wsgiref :
from wsgiref.simple_server import make_server
make_server('',8080,application).serve_forever()
init
pid: 1868 id: 3082036284 id.__dict__: 3082022260
pid: 1868 id: 3082036284 id.__dict__: 3082022260
pid: 1868 id: 3082036284 id.__dict__: 3082022260
pid: 1868 id: 3082036284 id.__dict__: 3082022260
pid: 1868 id: 3082036284 id.__dict__: 3082022260
I'll look if i can reproduce this with the code of _threading_local
--
William Dodé - http://flibuste.net
Informaticien Indépendant
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
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
-~--~~~~--~~--~--~---
