cogen - Project Hosting on Google Code

Earlier this year Sep 19, 2009 issue 16 (WaitForSignal with very short timeouts fails removing itself...) reported by maxim.krikun - Sometimes a WaitForSignal operation tries to remove itself from sched.timeouts, while it's not there. In my application (which runs socket io + tkinter update loop, and is very signal-intensive), this happens only once in hour on average, and seems pretty random. My guess is that it happens when an OperationTimeout exception is added to sched.active queue, while the same WaitForSignal operation is already on sched.active. I was able to isolate a failure in a relatively simple script (attached); it fails quickly (~10-20 seconds) when ran under Mac OS X on a macbook. Sample failure output is attached as well. The failure condition depends on a timeout scale parameter (currently, 0.05 inside rtime() function); if the error can't be readily reproduced on your system, try varying this parameter. Sometimes a WaitForSignal operation tries to remove itself from sched.timeouts, while it's not there. In my application (which runs socket io + tkinter update loop, and is very signal-intensive), this happens only once in hour on average, and seems pretty random. My guess is that it happens when an OperationTimeout exception is added to sched.active queue, while the same WaitForSignal operation is already on sched.active. I was able to isolate a failure in a relatively simple script (attached); it fails quickly (~10-20 seconds) when ran under Mac OS X on a macbook. Sample failure output is attached as well. The failure condition depends on a timeout scale parameter (currently, 0.05 inside rtime() function); if the error can't be readily reproduced on your system, try varying this parameter. Sep 17, 2009 issue 14 (WSGI upload speed is .12 kb/s) Labels changed by ionel.mc - Labels: Component-Docs Labels: Component-Docs Sep 16, 2009 issue 14 (WSGI upload speed is .12 kb/s) commented on by samuraiblog - you seem to have spotted my error. thank you for helping, upload speed is now very quick! Thanks! you seem to have spotted my error. thank you for helping, upload speed is now very quick! Thanks! Sep 16, 2009 issue 15 (missing wsgi.input in ENVIRON in pylons embed in cogen.wsgi....) Labels changed by ionel.mc - Actually cogen beeing an asynchronous server doesn't read the request body - it leaves it unread so the application can read it asynchronously (via environ["cogen.input"]). Apps that want want the old synchronous input (environ["wsgi.input"]) must use a piece of middleware (cogen.web.async.sync_input). See: http://code.google.com/p/cogen/source/browse/trunk/cogen/web/async.py#100 I'll have to add this to the docs and also maybe add this as a wsgi server option. In this regard cogen doesn't fully follow the wsgi spec but there's that sync_input middleware waiting to be added on the stack :) Labels: Component-Docs Actually cogen beeing an asynchronous server doesn't read the request body - it leaves it unread so the application can read it asynchronously (via environ["cogen.input"]). Apps that want want the old synchronous input (environ["wsgi.input"]) must use a piece of middleware (cogen.web.async.sync_input). See: http://code.google.com/p/cogen/source/browse/trunk/cogen/web/async.py#100 I'll have to add this to the docs and also maybe add this as a wsgi server option. In this regard cogen doesn't fully follow the wsgi spec but there's that sync_input middleware waiting to be added on the stack :) Labels: Component-Docs Sep 16, 2009 issue 15 (missing wsgi.input in ENVIRON in pylons embed in cogen.wsgi....) reported by n.vandamme - What steps will reproduce the problem? 1. My cogen handler (embedding a pylons app): config_path = os.path.abspath(os.path.dirname(server['config_file'])) path = '%s/%s' % (config_path, server['config_file']) wsgi_app = paste.deploy.loadapp('config:%s' % path) try: server_factory('config:%s' % path, server['address'], server['port'])(wsgi_app) except KeyboardInterrupt: return 1 except SystemExit: pass except: import traceback traceback.print_exc() 3. doing an abort(401) in one of my controllers 2. Traceback: Traceback (most recent call last): File "build/bdist.macosx-10.6-universal/egg/cogen/web/wsgi.py", line 416, in run response = self.wsgi_app(ENVIRON, self.start_response) File "/Users/nvandamme/Workspace/testings/lib/python2.6/site-packages/Paste-1.7.3dev_r0-py2.6.egg/paste/translogger.py", line 68, in __call__ return self.application(environ, replacement_start_response) File "/Users/nvandamme/Workspace/testings/lib/python2.6/site-packages/Paste-1.7.3dev_r0-py2.6.egg/paste/cascade.py", line 107, in __call__ f = StringIO(environ['wsgi.input'].read(length)) AttributeError: 'NoneType' object has no attribute 'read' What version of the product are you using? On what operating system? I'm using cogen (1.2.1-dev) from svn on Mac OSX 10.6 under python 2.6. To avoid Paste from throwing on error on environ['wsgi-input'] i change the following in cogen.web.wsgi: Right before line 414: + if not 'wsgi.input' in ENVIRON: + ENVIRON['wsgi.input'] = StringIO.StringIO() + elif not hasattr(ENVIRON['wsgi.input'], 'read'): + if ENVIRON['wsgi.input'] != None: + inp = ENVIRON['wsgi.input'] + ENVIRON['wsgi.input'] = StringIO.StringIO() + ENVIRON['wsgi.input'].write(inp) + else: + ENVIRON['wsgi.input'] = StringIO.StringIO() 414 response = self.wsgi_app(ENVIRON, self.start_response) What steps will reproduce the problem? 1. My cogen handler (embedding a pylons app): config_path = os.path.abspath(os.path.dirname(server['config_file'])) path = '%s/%s' % (config_path, server['config_file']) wsgi_app = paste.deploy.loadapp('config:%s' % path) try: server_factory('config:%s' % path, server['address'], server['port'])(wsgi_app) except KeyboardInterrupt: return 1 except SystemExit: pass except: import traceback traceback.print_exc() 3. doing an abort(401) in one of my controllers 2. Traceback: Traceback (most recent call last): File "build/bdist.macosx-10.6-universal/egg/cogen/web/wsgi.py", line 416, in run response = self.wsgi_app(ENVIRON, self.start_response) File "/Users/nvandamme/Workspace/testings/lib/python2.6/site-packages/Paste-1.7.3dev_r0-py2.6.egg/paste/translogger.py", line 68, in __call__ return self.application(environ, replacement_start_response) File "/Users/nvandamme/Workspace/testings/lib/python2.6/site-packages/Paste-1.7.3dev_r0-py2.6.egg/paste/cascade.py", line 107, in __call__ f = StringIO(environ['wsgi.input'].read(length)) AttributeError: 'NoneType' object has no attribute 'read' What version of the product are you using? On what operating system? I'm using cogen (1.2.1-dev) from svn on Mac OSX 10.6 under python 2.6. To avoid Paste from throwing on error on environ['wsgi-input'] i change the following in cogen.web.wsgi: Right before line 414: + if not 'wsgi.input' in ENVIRON: + ENVIRON['wsgi.input'] = StringIO.StringIO() + elif not hasattr(ENVIRON['wsgi.input'], 'read'): + if ENVIRON['wsgi.input'] != None: + inp = ENVIRON['wsgi.input'] + ENVIRON['wsgi.input'] = StringIO.StringIO() + ENVIRON['wsgi.input'].write(inp) + else: + ENVIRON['wsgi.input'] = StringIO.StringIO() 414 response = self.wsgi_app(ENVIRON, self.start_response) Sep 15, 2009 r593 (Changed the wsgi server so it properly uses the sockoper_tim...) committed by ionel.mc - Changed the wsgi server so it properly uses the sockoper_timeout option on the new connections. Changed the wsgi server so it properly uses the sockoper_timeout option on the new connections. Sep 15, 2009 r592 (Added a fix for a case when a timeout is raised (and the ass...) committed by ionel.mc - Added a fix for a case when a timeout is raised (and the associated socket subsequently removed from the proactor) and the socket _proactor_added flag remains to true Added a fix for a case when a timeout is raised (and the associated socket subsequently removed from the proactor) and the socket _proactor_added flag remains to true Sep 15, 2009 issue 14 (WSGI upload speed is .12 kb/s) commented on by ionel.mc - I can't reproduce it - however, you must do content-length boundary checking in the wsgi app like here: http://code.google.com/p/cogen/source/browse/trunk/cogen/web/async.py#109 I can't reproduce it - however, you must do content-length boundary checking in the wsgi app like here: http://code.google.com/p/cogen/source/browse/trunk/cogen/web/async.py#109 Sep 14, 2009 issue 14 (WSGI upload speed is .12 kb/s) commented on by samuraiblog - something like this... sorry for the mess something like this... sorry for the mess Sep 14, 2009 issue 14 (WSGI upload speed is .12 kb/s) commented on by ionel.mc - Can you attach a test client for this ? Can you attach a test client for this ? Sep 14, 2009 issue 14 (WSGI upload speed is .12 kb/s) reported by samuraiblog - Using the latest trunk I am using the cogen.wsgi server to handle file uploads with this code: buff = StringIO() stalled = False while not stalled: yield environ['cogen.input'].readline() #read(1024) #readline(512) result = environ['cogen.wsgi'].result if isinstance(result, events.OperationTimeout): stalled = True elif isinstance(result, Exception): import traceback traceback.print_exception(environ['cogen.wsgi'].exception) else: if not result: break buff.write(result) However a 3.8 kb gzip file is taking 30 seconds to upload. py2.6 builtin epoll is available. Running on a debian etch server VPS, and my development machine (mac os x) gives the same results. I've tried using different read ops, ie: readline(512), readline(8192), read(8192), read(512), but none seem to give any benefit. Using the latest trunk I am using the cogen.wsgi server to handle file uploads with this code: buff = StringIO() stalled = False while not stalled: yield environ['cogen.input'].readline() #read(1024) #readline(512) result = environ['cogen.wsgi'].result if isinstance(result, events.OperationTimeout): stalled = True elif isinstance(result, Exception): import traceback traceback.print_exception(environ['cogen.wsgi'].exception) else: if not result: break buff.write(result) However a 3.8 kb gzip file is taking 30 seconds to upload. py2.6 builtin epoll is available. Running on a debian etch server VPS, and my development machine (mac os x) gives the same results. I've tried using different read ops, ie: readline(512), readline(8192), read(8192), read(512), but none seem to give any benefit. Jun 19, 2009 issue 13 (ChatApp crashes) commented on by radaczynski - Great, thanks for that. Great, thanks for that. Jun 18, 2009 issue 13 (ChatApp crashes) commented on by ionel.mc - There's isn't a test.ini in the ChatApp. There is a cogen.ini that has the right settings and you should run the app with that. Or edit your settings and have this in the configuration .ini: [server:main] use = egg:cogen#http host = 0.0.0.0 port = 5001 There's isn't a test.ini in the ChatApp. There is a cogen.ini that has the right settings and you should run the app with that. Or edit your settings and have this in the configuration .ini: [server:main] use = egg:cogen#http host = 0.0.0.0 port = 5001 Jun 18, 2009 issue 13 (ChatApp crashes) commented on by radaczynski - isn't this supposed to be just the coroutine middleware? You wrote (http://ionelmc.wordpress.com/2008/04/29/comet-chat-in-pylons-with-cogen/): Once you have installed cogen (easy_install or setup.py develop), install the ChatApp (setup.py develop) and start the app with paster serve test.ini. And try finding some bugs (just joking) at http://127.0.0.1:5000/ this is exactly what I did. I don't really get what you mean by cogen's wsgi server... isn't this supposed to be just the coroutine middleware? You wrote (http://ionelmc.wordpress.com/2008/04/29/comet-chat-in-pylons-with-cogen/): Once you have installed cogen (easy_install or setup.py develop), install the ChatApp (setup.py develop) and start the app with paster serve test.ini. And try finding some bugs (just joking) at http://127.0.0.1:5000/ this is exactly what I did. I don't really get what you mean by cogen's wsgi server... Jun 18, 2009 issue 13 (ChatApp crashes) Status changed by ionel.mc - this needs to be run with cogen's wsgi server as the application uses the coroutine wsgi extensions Status: Invalid this needs to be run with cogen's wsgi server as the application uses the coroutine wsgi extensions Status: Invalid Jun 18, 2009 issue 13 (ChatApp crashes) reported by radaczynski - After downloading and settiing up the ChatApp, and issuing paster serve I get the following error: Exception happened during processing of request from ('127.0.0.1', 51137) Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/paste/httpserver.py", line 1062, in process_request_in_thread self.finish_request(request, client_address) File "/usr/lib/python2.6/SocketServer.py", line 320, in finish_request self.RequestHandlerClass(request, client_address, self) File "/usr/lib/python2.6/SocketServer.py", line 615, in __init__ self.handle() File "/usr/local/lib/python2.6/dist-packages/paste/httpserver.py", line 436, in handle BaseHTTPRequestHandler.handle(self) File "/usr/lib/python2.6/BaseHTTPServer.py", line 329, in handle self.handle_one_request() File "/usr/local/lib/python2.6/dist-packages/paste/httpserver.py", line 431, in handle_one_request self.wsgi_execute() File "/usr/local/lib/python2.6/dist-packages/paste/httpserver.py", line 289, in wsgi_execute for chunk in result: File "build/bdist.linux-x86_64/egg/cogen/web/async.py", line 111, in __call__ remaining = content_length = environ['cogen.wsgi'].content_length or 0 KeyError: 'cogen.wsgi' any help would be appreciated. Thanks. After downloading and settiing up the ChatApp, and issuing paster serve I get the following error: Exception happened during processing of request from ('127.0.0.1', 51137) Traceback (most recent call last): File "/usr/local/lib/python2.6/dist-packages/paste/httpserver.py", line 1062, in process_request_in_thread self.finish_request(request, client_address) File "/usr/lib/python2.6/SocketServer.py", line 320, in finish_request self.RequestHandlerClass(request, client_address, self) File "/usr/lib/python2.6/SocketServer.py", line 615, in __init__ self.handle() File "/usr/local/lib/python2.6/dist-packages/paste/httpserver.py", line 436, in handle BaseHTTPRequestHandler.handle(self) File "/usr/lib/python2.6/BaseHTTPServer.py", line 329, in handle self.handle_one_request() File "/usr/local/lib/python2.6/dist-packages/paste/httpserver.py", line 431, in handle_one_request self.wsgi_execute() File "/usr/local/lib/python2.6/dist-packages/paste/httpserver.py", line 289, in wsgi_execute for chunk in result: File "build/bdist.linux-x86_64/egg/cogen/web/async.py", line 111, in __call__ remaining = content_length = environ['cogen.wsgi'].content_length or 0 KeyError: 'cogen.wsgi' any help would be appreciated. Thanks. Apr 26, 2009 issue 11 (Completed operations not removed from timeouts list) Status changed by ionel.mc - Status: Fixed Status: Fixed Apr 26, 2009 issue 12 (StdlibKQueueProactor automatic use) Status changed by ionel.mc - Looks like I just forgot to add has_stdlib_kqueue in has_any. I have a test freebsd vm though. I've fixed it in trunk. Status: Fixed Looks like I just forgot to add has_stdlib_kqueue in has_any. I have a test freebsd vm though. I've fixed it in trunk. Status: Fixed Apr 26, 2009 r591 (forgot to add has_stdlib_kqueue into has_any) committed by ionel.mc - forgot to add has_stdlib_kqueue into has_any forgot to add has_stdlib_kqueue into has_any Apr 26, 2009 issue 12 (StdlibKQueueProactor automatic use) reported by lasizoillo - In the last code: http://code.google.com/p/cogen/source/browse/trunk/cogen/core/proactors/__init__.py#91 return get_first(has_ctypes_iocp, has_iocp, has_kqueue, has_stdlib_epoll, has_epoll, has_poll, has_select) has_stdlib_kqueue is not called. Maybe your are waiting for a FreeBSD Ok test. It's attached. In the last code: http://code.google.com/p/cogen/source/browse/trunk/cogen/core/proactors/__init__.py#91 return get_first(has_ctypes_iocp, has_iocp, has_kqueue, has_stdlib_epoll, has_epoll, has_poll, has_select) has_stdlib_kqueue is not called. Maybe your are waiting for a FreeBSD Ok test. It's attached. Apr 26, 2009 issue 11 (Completed operations not removed from timeouts list) Status changed by ionel.mc - It looks like it's a general problem with coroutines that generate large amounts of operations with a timeout so I'm adding a fix in trunk that removes the timeouts on the operation's finalize method. Test and report if you have any problems or performance issues. Status: Started It looks like it's a general problem with coroutines that generate large amounts of operations with a timeout so I'm adding a fix in trunk that removes the timeouts on the operation's finalize method. Test and report if you have any problems or performance issues. Status: Started Apr 26, 2009 r590 (Updated the license years and one more whitespace fix.) committed by ionel.mc - Updated the license years and one more whitespace fix. Updated the license years and one more whitespace fix. Apr 26, 2009 r589 (Added forgotten license file.) committed by ionel.mc - Added forgotten license file. Added forgotten license file. Apr 26, 2009 r588 (Removed trailing spaces. Fixed inconsistent end of line form...) committed by ionel.mc - Removed trailing spaces. Fixed inconsistent end of line format. Merged from amcnabb8's branch. Removed trailing spaces. Fixed inconsistent end of line format. Merged from amcnabb8's branch. Apr 26, 2009 r587 (changed CoroGreenlet to take the sched param on finalize) committed by ionel.mc - changed CoroGreenlet to take the sched param on finalize changed CoroGreenlet to take the sched param on finalize Apr 26, 2009 r586 (added an 'sched' param to Operation's finalize method thourg...) committed by ionel.mc - added an 'sched' param to Operation's finalize method thourgh all the code to support additional cleanup (mainly for TimedOperation to remove itself from the timeouts heapq on finalization) added an 'sched' param to Operation's finalize method thourgh all the code to support additional cleanup (mainly for TimedOperation to remove itself from the timeouts heapq on finalization) Apr 26, 2009 r585 (changed socketlets.Socket to have makefile working in the sa...) committed by ionel.mc - changed socketlets.Socket to have makefile working in the same way as the one in stdlib (that is dupe the socket on makefile) changed socketlets.Socket to have makefile working in the same way as the one in stdlib (that is dupe the socket on makefile) Apr 26, 2009 r584 (changed sockets.Socket to support instance duping) committed by ionel.mc - changed sockets.Socket to support instance duping changed sockets.Socket to support instance duping Apr 26, 2009 r583 (made socket import from stdlib more explicit) committed by ionel.mc - made socket import from stdlib more explicit made socket import from stdlib more explicit Apr 17, 2009 r582 (Changed all cogen imports to be relative imports.) committed by amcnabb8 - Changed all cogen imports to be relative imports. Changed all cogen imports to be relative imports. Apr 17, 2009 r581 (Created a branch for Python 2.5 style relative imports. ) committed by amcnabb8 - Created a branch for Python 2.5 style relative imports. Created a branch for Python 2.5 style relative imports. Apr 17, 2009 r580 (Removed trailing spaces.) committed by amcnabb8 - Removed trailing spaces. Removed trailing spaces. Apr 17, 2009 r579 (Fixed inconsistent end of line format. Although most of the...) committed by amcnabb8 - Fixed inconsistent end of line format. Although most of the project was using the DOS end of line format (CRLF), there were still a large number of files using Unix newlines. Many files were internally inconsistent. This has been fixed throughout the cogen, docs, and examples directories. I skipped the docs/build directory because it is autogenerated and lib directory since it contains code from external projects. Fixed inconsistent end of line format. Although most of the project was using the DOS end of line format (CRLF), there were still a large number of files using Unix newlines. Many files were internally inconsistent. This has been fixed throughout the cogen, docs, and examples directories. I skipped the docs/build directory because it is autogenerated and lib directory since it contains code from external projects. Apr 17, 2009 r578 (Created a branch for whitespace cleanups. ) committed by amcnabb8 - Created a branch for whitespace cleanups. Created a branch for whitespace cleanups. Apr 10, 2009 r577 (added back the warning for old win32file module) committed by ionel.mc - added back the warning for old win32file module added back the warning for old win32file module Apr 08, 2009 issue 11 (Completed operations not removed from timeouts list) commented on by wonderclown - That's true, if the heapq is large. One possibility would be to maintain a counter of the number of stale items on the timeouts heapq. Whenever an operation is completed, it could increment this counter if it has a timeout set. It would be decremented as timeouts are processed. If the counter gets large, it could initiate a pass over the heapq to remove all stale operations. It would probably be best to define "large" as a percentage of the total size of the heapq -- say 70%. In this case, it will probably be more efficient to traverse the heapq, copying only live operations into a new heapq, and then discarding the old heapq. This would allow stale operations to live for a while, but they will be cleaned up periodically, which solves the problem of ever-growing memory usage in my scenario. An alternative heuristic would be to look at how far in the future the timeout is, and if the timeout is soon, don't worry about it, but if it's a while, better to clean it up and free the memory. What "far in the future" means probably depends on the application, and so should be tweakable by the programmer. Or you could say that the overhead of the extra bookkeeping isn't worth it for most applications, and just provide a method on Scheduler for the programmer to manually trigger a traversal of the heapq, for those rare apps that need such a feature. That's true, if the heapq is large. One possibility would be to maintain a counter of the number of stale items on the timeouts heapq. Whenever an operation is completed, it could increment this counter if it has a timeout set. It would be decremented as timeouts are processed. If the counter gets large, it could initiate a pass over the heapq to remove all stale operations. It would probably be best to define "large" as a percentage of the total size of the heapq -- say 70%. In this case, it will probably be more efficient to traverse the heapq, copying only live operations into a new heapq, and then discarding the old heapq. This would allow stale operations to live for a while, but they will be cleaned up periodically, which solves the problem of ever-growing memory usage in my scenario. An alternative heuristic would be to look at how far in the future the timeout is, and if the timeout is soon, don't worry about it, but if it's a while, better to clean it up and free the memory. What "far in the future" means probably depends on the application, and so should be tweakable by the programmer. Or you could say that the overhead of the extra bookkeeping isn't worth it for most applications, and just provide a method on Scheduler for the programmer to manually trigger a traversal of the heapq, for those rare apps that need such a feature. Apr 08, 2009 issue 11 (Completed operations not removed from timeouts list) commented on by ionel.mc - This could be implemented in TimedOperation.cleanup - however, removing arbitrary items from the timeouts heapq might impact performance. This could be implemented in TimedOperation.cleanup - however, removing arbitrary items from the timeouts heapq might impact performance. Apr 07, 2009 issue 11 (Completed operations not removed from timeouts list) reported by wonderclown - Steps to reproduce: 1. Queue an operation with a timeout far in the future 2. Let the operation succeed 3. The operation will still be in the Scheduler.timeouts list If you happen to create a large number of such operations, your app will leak memory due to these old operations still being on the timeouts list. It seems to be that process_op should check to see if the operation it just processed is on the timeouts list, and remove it if so. Steps to reproduce: 1. Queue an operation with a timeout far in the future 2. Let the operation succeed 3. The operation will still be in the Scheduler.timeouts list If you happen to create a large number of such operations, your app will leak memory due to these old operations still being on the timeouts list. It seems to be that process_op should check to see if the operation it just processed is on the timeouts list, and remove it if so. Mar 03, 2009 r576 (added a example with httplib and corolets) committed by ionel.mc - added a example with httplib and corolets added a example with httplib and corolets Mar 03, 2009 r575 (import the socket class directly) committed by ionel.mc - import the socket class directly import the socket class directly Feb 11, 2009 r574 (updated docs) committed by ionel.mc - updated docs updated docs Feb 11, 2009 r573 (changed how Scheduler is cleaned up) committed by ionel.mc - changed how Scheduler is cleaned up changed how Scheduler is cleaned up Jan 19, 2009 py-1.0.0a1.win32-py2.6.exe (py.lib build that works on windows python 2.6) file uploaded by ionel.mc Jan 18, 2009 r572 (cleaned up some examples) committed by ionel.mc - cleaned up some examples cleaned up some examples Jan 18, 2009 r571 (added an echoserver using corolets) committed by ionel.mc - added an echoserver using corolets added an echoserver using corolets Jan 18, 2009 r570 (changed a repr string) committed by ionel.mc - changed a repr string changed a repr string Jan 18, 2009 r569 (added a Coroutine spin-off that uses greenlets behind the sc...) committed by ionel.mc - added a Coroutine spin-off that uses greenlets behind the scenes instead of generator schematics added a Coroutine spin-off that uses greenlets behind the scenes instead of generator schematics Jan 18, 2009 r568 (changed the constructor for the new socket from accept to be...) committed by ionel.mc - changed the constructor for the new socket from accept to be the same as the acceptor socket's class changed the constructor for the new socket from accept to be the same as the acceptor socket's class Jan 18, 2009 r567 (changed message for an assertion) committed by ionel.mc - changed message for an assertion changed message for an assertion Jan 17, 2009 r566 ([No log message]) committed by ionel.mc - [No log message] [No log message]

issue 15 (missing wsgi.input in ENVIRON in pylons embed in cogen.wsgi....) reported by n.vandamme - What steps will reproduce the problem? 1. My cogen handler (embedding a pylons app): config_path = os.path.abspath(os.path.dirname(server['config_file'])) path = '%s/%s' % (config_path, server['config_file']) wsgi_app = paste.deploy.loadapp('config:%s' % path) try: server_factory('config:%s' % path, server['address'], server['port'])(wsgi_app) except KeyboardInterrupt: return 1 except SystemExit: pass except: import traceback traceback.print_exc() 3. doing an abort(401) in one of my controllers 2. Traceback: Traceback (most recent call last): File "build/bdist.macosx-10.6-universal/egg/cogen/web/wsgi.py", line 416, in run response = self.wsgi_app(ENVIRON, self.start_response) File "/Users/nvandamme/Workspace/testings/lib/python2.6/site-packages/Paste-1.7.3dev_r0-py2.6.egg/paste/translogger.py", line 68, in __call__ return self.application(environ, replacement_start_response) File "/Users/nvandamme/Workspace/testings/lib/python2.6/site-packages/Paste-1.7.3dev_r0-py2.6.egg/paste/cascade.py", line 107, in __call__ f = StringIO(environ['wsgi.input'].read(length)) AttributeError: 'NoneType' object has no attribute 'read' What version of the product are you using? On what operating system? I'm using cogen (1.2.1-dev) from svn on Mac OSX 10.6 under python 2.6. To avoid Paste from throwing on error on environ['wsgi-input'] i change the following in cogen.web.wsgi: Right before line 414: + if not 'wsgi.input' in ENVIRON: + ENVIRON['wsgi.input'] = StringIO.StringIO() + elif not hasattr(ENVIRON['wsgi.input'], 'read'): + if ENVIRON['wsgi.input'] != None: + inp = ENVIRON['wsgi.input'] + ENVIRON['wsgi.input'] = StringIO.StringIO() + ENVIRON['wsgi.input'].write(inp) + else: + ENVIRON['wsgi.input'] = StringIO.StringIO() 414 response = self.wsgi_app(ENVIRON, self.start_response)

What steps will reproduce the problem? 1. My cogen handler (embedding a pylons app): config_path = os.path.abspath(os.path.dirname(server['config_file'])) path = '%s/%s' % (config_path, server['config_file']) wsgi_app = paste.deploy.loadapp('config:%s' % path) try: server_factory('config:%s' % path, server['address'], server['port'])(wsgi_app) except KeyboardInterrupt: return 1 except SystemExit: pass except: import traceback traceback.print_exc() 3. doing an abort(401) in one of my controllers 2. Traceback: Traceback (most recent call last): File "build/bdist.macosx-10.6-universal/egg/cogen/web/wsgi.py", line 416, in run response = self.wsgi_app(ENVIRON, self.start_response) File "/Users/nvandamme/Workspace/testings/lib/python2.6/site-packages/Paste-1.7.3dev_r0-py2.6.egg/paste/translogger.py", line 68, in __call__ return self.application(environ, replacement_start_response) File "/Users/nvandamme/Workspace/testings/lib/python2.6/site-packages/Paste-1.7.3dev_r0-py2.6.egg/paste/cascade.py", line 107, in __call__ f = StringIO(environ['wsgi.input'].read(length)) AttributeError: 'NoneType' object has no attribute 'read' What version of the product are you using? On what operating system? I'm using cogen (1.2.1-dev) from svn on Mac OSX 10.6 under python 2.6. To avoid Paste from throwing on error on environ['wsgi-input'] i change the following in cogen.web.wsgi: Right before line 414: + if not 'wsgi.input' in ENVIRON: + ENVIRON['wsgi.input'] = StringIO.StringIO() + elif not hasattr(ENVIRON['wsgi.input'], 'read'): + if ENVIRON['wsgi.input'] != None: + inp = ENVIRON['wsgi.input'] + ENVIRON['wsgi.input'] = StringIO.StringIO() + ENVIRON['wsgi.input'].write(inp) + else: + ENVIRON['wsgi.input'] = StringIO.StringIO() 414 response = self.wsgi_app(ENVIRON, self.start_response)

Earlier this year