From: Sophana K <sop...@gm...> - 2012-09-17 09:27:39
|
Hi I'm using webware for my website since 2007. I'm using webware 1.0, because webware 1.1 didn't work correctly for me (I don't remember why) I'm currently trying to debug a freeze problem that occur every 1 to 3 weeks. The python appServer process is completely frozen, and must be killed with -9. It doesn't respond to any signal, so I can't dump its stack, and really don't know the cause strace shows that python is waiting on a futex. I still have some actions to do in my investigations like: - rebooting the server which is up since 620 days... - separating the custom radius server I made which is launched in the same process in several new threads. (I didn't know about the GIL at that time...) - reverting to webware 0.9 I intend to use gevent for the radius server, because I like it. I would also like to use comet services for the web application, which brings me to my question: I've seen that there is a WSGI adapter that connects to the appServer. Is it possible to wrap a webware application in a real WSGI handler? This would allow to use webware applications under modern servers like gevent (gunicorn) and why not google app engine. The threaded app server is no more adapted to modern web techniques. A gevent based appServer would be so great! libraries like gevent-zeromq and gevent-socketio would be so nice to have. Gevent is able to wrap standard python libraries (monkey patching) and make standard code greenlet compatible, so I'm not sure the wsgi wrapper would be complicated to do. I have started to look inside the appServer. I don't know where to start. There are quite some code that initializes different modules and things like that. In gevent, the idea is to spawn a greenlet for every new transaction. I'm not sure there is a pool of workers. Thanks for reading. |
From: Christoph Z. <ci...@on...> - 2012-09-19 15:01:38
|
Am 17.09.2012 11:27, schrieb Sophana K: > I'm using webware 1.0, because webware 1.1 didn't work correctly for > me (I don't remember why) You should definitely try 1.1 again. It works great for me and if there are any real issues, please report and I'll be glad to fix them. > I'm currently trying to debug a freeze problem that occur every 1 to > 3 weeks.The python appServer process is completely frozen, and must > be killed with -9.It doesn't respond to any signal, so I can't dump > its stack, and really don't know the cause strace shows that python > is waiting on a futex. Again, I don't think this is a problem with Webware itself. I have my Webware 1.1 apps running on many servers for months without restart. > I still have some actions to do in my investigations like: > - separating the custom radius server I made which is launched in the > same process in several new threads. (I didn't know about the GIL at > that time...) This could really be the problem. You should run it in a separate process. > - reverting to webware 0.9 Don't do that. There have been many bugfixes and improvements in 1.x. > I've seen that there is a WSGI adapter that connects to the appServer. > Is it possible to wrap a webware application in a real WSGI handler? > This would allow to use webware applications under modern servers > like gevent (gunicorn) and why not google app engine. The threaded > app server is no more adapted to modern web techniques. A gevent > based appServer would be so great! libraries like gevent-zeromq and > gevent-socketio would be so nice to have. Yes, the adapter needs a running appserver. This has also advantages, because it decouples your WSGI server from the application. But you're right, it would be nice to have an option to run Webware applications without the AppServer, directly wrapped as WSGI, so we could make use of existing non-threaded WSGI servers. Actually, I discussed these ideas already years ago on this mailing list. However, there was not so much feedback and I had not enough time to realize it, so these ideas were not realized so far. So my question to this mailing list would be: How many people are still interested in having a modernized Webware version? How backward compatible must it be? Would it be ok to change package and method names to make them comply with PEP8 or to change getter functions to properties or should it be as compatible as possible? Which plugins and functionality should still be supported, what can be stripped away (personally, I'm using only WebKit)? -- Christoph |
From: Oliver B. <ol...@g7...> - 2012-09-19 22:48:40
|
On 20/09/2012 1:01 AM, Christoph Zwerschke wrote: > So my question to this mailing list would be: How many people are still > interested in having a modernized Webware version...? I maintain a Webware app that does a lot of work, but changes rarely, and I'm not doing any new Python web development these days (I'm using C# so I can share code between a desktop app and web server). I only use mod_webkit2, WebKit and MiscUtils.DBPool. My preference would be to keep up with Python so I can keep installing Webware when CentOS upgrades its python, but otherwise stability is good for me. That said, none of the suggestions for updating APIs would particularly bother me - I like WebKit and will happily do what it takes to keep my application working. And thanks for all the work you do keeping it going, Christoph. Oliver |
From: NoRaGen <no...@gm...> - 2012-09-19 16:13:24
|
Hi, It would be nice to have the option to upgrade to a python3.x Version of Webware for later purpose. Backward Compatiblity would be nice until python2.5 (python2.6 is buggy) We currently don't use WSGI capability, we use WebKit at all. Compatiblity should be given so, that API remains the same, but using python3.x capability. This should be possible, I think. API changes would very bad at all. I have seen it at the print-function in python3. To port thousands of such places is a real overkill. This API-Change is really the worst of all. I simply can't understand why the didn't wrote an enhanced function for this... However we use many modules where still no python3 port is existing. For now, switching to higher python version, would still not effective for us. Best Regards Tobias ------------------------------------------------------------------------ Am 19.09.2012 17:01, schrieb Christoph Zwerschke: > Am 17.09.2012 11:27, schrieb Sophana K: >> I'm using webware 1.0, because webware 1.1 didn't work correctly for >> me (I don't remember why) > You should definitely try 1.1 again. It works great for me and if there > are any real issues, please report and I'll be glad to fix them. > >> I'm currently trying to debug a freeze problem that occur every 1 to >> 3 weeks.The python appServer process is completely frozen, and must >> be killed with -9.It doesn't respond to any signal, so I can't dump >> its stack, and really don't know the cause strace shows that python >> is waiting on a futex. > Again, I don't think this is a problem with Webware itself. I have my > Webware 1.1 apps running on many servers for months without restart. > >> I still have some actions to do in my investigations like: >> - separating the custom radius server I made which is launched in the >> same process in several new threads. (I didn't know about the GIL at >> that time...) > This could really be the problem. You should run it in a separate process. > >> - reverting to webware 0.9 > Don't do that. There have been many bugfixes and improvements in 1.x. > >> I've seen that there is a WSGI adapter that connects to the appServer. >> Is it possible to wrap a webware application in a real WSGI handler? >> This would allow to use webware applications under modern servers >> like gevent (gunicorn) and why not google app engine. The threaded >> app server is no more adapted to modern web techniques. A gevent >> based appServer would be so great! libraries like gevent-zeromq and >> gevent-socketio would be so nice to have. > Yes, the adapter needs a running appserver. This has also advantages, > because it decouples your WSGI server from the application. > > But you're right, it would be nice to have an option to run Webware > applications without the AppServer, directly wrapped as WSGI, so we > could make use of existing non-threaded WSGI servers. Actually, I > discussed these ideas already years ago on this mailing list. However, > there was not so much feedback and I had not enough time to realize it, > so these ideas were not realized so far. > > So my question to this mailing list would be: How many people are still > interested in having a modernized Webware version? How backward > compatible must it be? Would it be ok to change package and method names > to make them comply with PEP8 or to change getter functions to > properties or should it be as compatible as possible? Which plugins and > functionality should still be supported, what can be stripped away > (personally, I'm using only WebKit)? > > -- Christoph > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: Christoph Z. <ci...@on...> - 2012-09-19 18:08:01
|
Am 19.09.2012 18:13, schrieb NoRaGen: > It would be nice to have the option to upgrade to a python3.x Version > of Webware for later purpose. Definitely, that has also been one of my goals for a new version. > Compatiblity should be given so, that API remains the same, but > using python3.x capability. This should be possible, I think. API > changes would very bad at all. The problem here is that Webware development started even before Python 2, so the old API is very old-fashioned concerning naming conventions, use of getters and setters etc. My idea was to add a tool like py2to3 that can convert an old style Webware app to a new style app. Another idea would be to allow both styles. E.g. request could become a property, but if you call the request object, then it returns self, so if you use request as a getter function, it would still work. We already discussed this in the past. Method names could be changed from camelCase to PEP8 style, but the old names could be kept as aliases. > However we use many modules where still no python3 port is existing. > For now, switching to higher python version, would still not > effective for us. Yes, e.g. ReportLab is still one of the roadblockers. -- Chris |
From: Sophana K <sop...@gm...> - 2012-09-20 07:59:59
|
I will give a try again with webware 1.1 It works, but not for a long time... python3 doesn't look like a priority for me. (I admit I had some hard time with unicode...) Backward compatibility for webkit is the most important IMHO. About naming convention, I don't care that much. I'm not using plugins. A little bit of TaskKit (not a big deal) Migrating to more modern server architectures is a big plus for me: more scalability, comet, etc... If it is possible to just use WebKit compatibility in order to integrate more easily with other python libraries, it would be great. Sophana On Wed, Sep 19, 2012 at 8:07 PM, Christoph Zwerschke <ci...@on...> wrote: > Am 19.09.2012 18:13, schrieb NoRaGen: >> It would be nice to have the option to upgrade to a python3.x Version >> of Webware for later purpose. > > Definitely, that has also been one of my goals for a new version. > > > Compatiblity should be given so, that API remains the same, but > > using python3.x capability. This should be possible, I think. API > > changes would very bad at all. > > The problem here is that Webware development started even before Python > 2, so the old API is very old-fashioned concerning naming conventions, > use of getters and setters etc. My idea was to add a tool like py2to3 > that can convert an old style Webware app to a new style app. > > Another idea would be to allow both styles. E.g. request could become a > property, but if you call the request object, then it returns self, so > if you use request as a getter function, it would still work. We already > discussed this in the past. Method names could be changed from camelCase > to PEP8 style, but the old names could be kept as aliases. > >> However we use many modules where still no python3 port is existing. >> For now, switching to higher python version, would still not >> effective for us. > > Yes, e.g. ReportLab is still one of the roadblockers. > > -- Chris > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss |