From: Terrel S. <tsh...@tr...> - 2001-03-09 05:52:27
|
What was the decision on supporting python 1.5.2 vs 2.0? In integrating SessionSQLStore I propose changing the SessionStore piece of Application.__init__ to read as follows: ----------- ## Session store # Create the session store session_config = self.setting("SessionStore") class_name = session_config["class"] # or "factory" path = class_name.split(".") class_name = path[-1] path = ".".join(path[:-1]) namespace={} module = __import__(path,namespace,namespace,[class_name]) factory = namespace[class_name] #this does not have to be a class, just a callable factory self._sessions = factory(self,session_config) ## End Session store ----------- This is more flexible than requiring a ClassType, and eliminates the need to import unused modules (especially important for OneShot). Application.config would have a dictionary value instead of a string value, e.g. ------- "SessionStore": "File", ==> "SessionStore": { "class": "WebKit.SessionFileStore.SessionFileStore", "folder": "/path/to/webware/WebKit/Sessions/", }, ------- Analogous changes apply to other stores (and of course, minor changes to the __init__ methods of the affected classes). In particular the SessionSQLStore config might look like this: ------- "SessionStore":{ "class": "WebKit.SessionSQLStore.SessionSQLStore", "session_table": "webkit_sessions", "connection": """## this string gets exec'ed. SessionSQLStore expects a name "connection" to refer to a DB API compliant Connection object import my_db_connection_pool connection = my_db_connection_pool.get_connection() """, # (OR, we could use the same strategy as with the factory in ##SessionStore of Application.__init__ (cleaner, but less flexible.)) } ------ If this is cool with everyone, I will build and submit a patch. --Terrel |
From: Terrel S. <tsh...@tr...> - 2001-03-12 22:00:20
|
Terrel Shumway wrote: > If this is cool with everyone, I will build and submit a patch. > I guess everyone here is very busy. Here is the patch anyway: http://www.ics.uci.edu/~tshumway/webware/sessionsqlstore.html Consider this an ALPHA release. I am posting it for the masochisitic. I'll-get-back-to-this-after-finals-are-over-ly yours, Terrel |
From: Tom S. <tom...@li...> - 2001-03-13 12:47:16
|
Terrel Shumway wrote: > > Terrel Shumway wrote: > > > If this is cool with everyone, I will build and submit a patch. > > > > I guess everyone here is very busy. Here is the patch anyway: > http://www.ics.uci.edu/~tshumway/webware/sessionsqlstore.html > Consider this an ALPHA release. I am posting it for the masochisitic. I'd like to test that, but I'm not able to patch it Your " (Created-By-Prcs-Version 1 2 15)" is not really compatible with Unix patch. Maybe you cound put the files you created or changed on the Website (zip-File to unpack in the Webware directory which overwrites all necessary files and creates the new ones), so one could play with it. Looks cool and was one of my "things to have" List at Python9 :-) -- Tom Schwaller http://www.linux-community.de |
From: Terrel S. <tsh...@tr...> - 2001-03-13 19:43:21
|
Tom Schwaller wrote: > Terrel Shumway wrote: > > > > Terrel Shumway wrote: > > > > > If this is cool with everyone, I will build and submit a patch. > > > > > > > I guess everyone here is very busy. Here is the patch anyway: > > http://www.ics.uci.edu/~tshumway/webware/sessionsqlstore.html > > Consider this an ALPHA release. I am posting it for the masochisitic. > > I'd like to test that, but I'm not able to patch it > Your " (Created-By-Prcs-Version 1 2 15)" is not really compatible > with Unix patch. Actually, it is a standard "diff -ru cvs.12 SessionBranch.2", just run against a PRCS repository. (PRCS handles branching an merging very nicely. http://xcf.berkeley.edu/~jmacd/prcs.html.) The problem is that the project descriptor file "ww-dev.prj" is my local file, not from the CVS repository. Oops. Oh. I guess there is an extra "Index: ..." line between each diff. Let me try again. > Maybe you cound put the files > you created or changed on the Website (zip-File to unpack > in the Webware directory which overwrites all necessary files and > creates the new ones), so one could play with it. I can do that too. > Looks cool and was one of my "things to have" List at Python9 :-) To me, it doesn't make a lot of sense to *not* use a database for session data: too many wheels to reinvent when using the file system. |
From: Terrel S. <tsh...@tr...> - 2001-03-13 22:11:10
|
Tom Schwaller wrote: > Terrel Shumway wrote: > > http://www.ics.uci.edu/~tshumway/webware/sessionsqlstore.html > > Consider this an ALPHA release. > > I am posting it for the masochisitic. You were warned. Warnings aside, I am embarassed by the low quality of the patch. I am sorry for wasting your time. (The code didn't work at all.) A new version is now available at the same URL. > I'd like to test that, but I'm not able to patch it > Your " (Created-By-Prcs-Version 1 2 15)" is not really compatible > with Unix patch. This time I did a real "diff -uNr" in a real filesystem. Please review the documentation, as it has changed. I cleaned up the names of the settings to use CapWords consistently. I also got rid of the exec kludge for getting the database connection, and added a *demonstration* of one way to get a db connection. You will need to change MySQLdbConnector.py to match your setup. |
From: Tom S. <tom...@li...> - 2001-03-14 03:20:30
|
Terrel Shumway wrote: > > Tom Schwaller wrote: > > > Terrel Shumway wrote: > > > http://www.ics.uci.edu/~tshumway/webware/sessionsqlstore.html > > > Consider this an ALPHA release. > > > > I am posting it for the masochisitic. > > You were warned. > > Warnings aside, I am embarassed by the low quality of the patch. I am > sorry for wasting your time. (The code didn't work at all.) A new version > is now available at the same URL. > > > I'd like to test that, but I'm not able to patch it > > Your " (Created-By-Prcs-Version 1 2 15)" is not really compatible > > with Unix patch. > > This time I did a real "diff -uNr" in a real filesystem. > > Please review the documentation, as it has changed. I cleaned up the names > of the settings to use CapWords consistently. I also got rid of the exec > kludge for getting the database connection, and added a *demonstration* of > one way to get a db connection. You will need to change > MySQLdbConnector.py to match your setup. ok, thanks a lot. It's on my list for tomorrow (I mean later today :-)) > To me, it doesn't make a lot of sense to *not* use a database for session > data: too many wheels to reinvent when using the file system. I agree, because this kind of data can grow really fast and it's much easier to delete old data by a simple DELETE .. WHERE date < ... command. B.T.W. I finally found a good solution how to run Zope on a site (everything under /) and plug in Webware for subdirectories like /Info transparently so people do not realize that I migrate parts of my website. -- Tom Schwaller http://www.linux-community.de |
From: Chuck E. <ec...@mi...> - 2001-03-14 14:07:29
|
At 04:27 AM 3/14/2001 +0100, Tom Schwaller wrote: >I agree, because this kind of data can grow really fast and it's much >easier to delete old data by a simple DELETE .. WHERE date < ... >command. Yeah, although most sites don't have different expiration times for settings. An additional configuration option like UniformSessionTimeouts = 1, would enable the mtime enhancement for sessions stored in files. I think both techniques are interesting and plan that WebKit should always support both very well. >B.T.W. I finally found a good solution how >to run Zope on a site (everything under /) and plug in >Webware for subdirectories like /Info transparently >so people do not realize that I migrate parts of my website. Um, you definitely need to write that up as a cookbook recipe thing. -Chuck |
From: Terrel S. <tsh...@tr...> - 2001-03-14 15:03:49
|
Chuck Esterbrook wrote: > At 04:27 AM 3/14/2001 +0100, Tom Schwaller wrote: > >I agree, because this kind of data can grow really fast and it's much > >easier to delete old data by a simple DELETE .. WHERE date < ... > >command. > > Yeah, although most sites don't have different expiration times for > settings. An additional configuration option like UniformSessionTimeouts = > 1, would enable the mtime enhancement for sessions stored in files. > > I think both techniques are interesting and plan that WebKit should always > support both very well. > That is a good idea. The file system is appropriate for some sites. Having a uniform session timeout makes it even more attractive. However, I think the more compelling reasons to use a database are: 1) locking and consistency issues are solved at a lower level (I have heard bad things about NFS) 2) session data is distributable (horizontal scaling) -- there is no need for "session affinity" in load balancing 3) failover -- one webserver can go down and the others can pick up the sessions BTW. Is anyone using webware in a setup that requires load balancing? Is anyone planning to do so? |
From: Chuck E. <ec...@mi...> - 2001-03-14 15:08:27
|
At 10:08 AM 3/14/2001 -0500, Terrel Shumway wrote: >That is a good idea. The file system is appropriate for some sites. Having a >uniform session timeout makes it even more attractive. > >However, I think the more compelling reasons to use a database are: > 1) locking and consistency issues are solved at a lower level (I have >heard bad things about NFS) Agreed. > 2) session data is distributable (horizontal scaling) -- there is no need >for "session affinity" in load balancing I'm curious about this. If you go with a SQL database in a multiple server box situation, don't they all have to hit the same SQL server on the same box? Where's the scaling? > 3) failover -- one webserver can go down and the others can pick up the >sessions > >BTW. Is anyone using webware in a setup that requires load balancing? Is >anyone planning to do so? Not yet that I know of. I'm sure someone will get to it soon. -Chuck |
From: Tom S. <tom...@li...> - 2001-03-14 15:39:18
|
Chuck Esterbrook wrote: > > At 04:27 AM 3/14/2001 +0100, Tom Schwaller wrote: > >B.T.W. I finally found a good solution how > >to run Zope on a site (everything under /) and plug in > >Webware for subdirectories like /Info transparently > >so people do not realize that I migrate parts of my website. > > Um, you definitely need to write that up as a cookbook recipe thing. > > -Chuck I've already documented it somewhat in German today https://www.linux-community.de/Neues/story?storyid=1134 here's a fast setup for https on Port 443 (you can use that in the main section too or at other places ..) I use mod_pcgi2 (start Zope with out HTTP and FTP server) e.g. ./start -f - -w - -m 12099 and put the following in httpd.conf LoadModule pcgi2_module lib/apache/libpcgi2.so AddModule mod_pcgi2.c ... <VirtualHost .....:443> <Location /> PCGI_NAME Zope PCGI_MODULE_PATH /usr/local/Zope/lib/python/Zope PCGI_PUBLISHER /usr/local/Zope/pcgi/pcgi_publisher.py PCGI_EXE /usr/bin/python PCGI_SOCKET_FILE /usr/local/Zope/var/pcgi.soc PCGI_PID_FILE /usr/local/Zope/var/pcgi.pid PCGI_ERROR_LOG /usr/local/Zope/var/pcgi.log PCGI_DISPLAY_ERRORS 0 SetHandler pcgi-handler PCGI_ROOT / PCGI_SetEnv SiteRootPATH / </Location> <Location /wpy> SetHandler webkit-handler </Location> </VirtualHost> <Location /wpy > needs to be AFTER <Location / > <-- very important No SiteAcces rules or whatever, just mod_*. The nice thing, you can just factor out other Locations (/News, /Info,...) when you prefer to do them with Webware instead of Zope. I like it :-)) -- Tom Schwaller http://www.linux-community.de |
From: Terrel S. <tsh...@tr...> - 2001-03-14 15:44:00
|
Chuck Esterbrook wrote: > At 10:08 AM 3/14/2001 -0500, Terrel Shumway wrote: > > 2) session data is distributable (horizontal scaling) -- there is no need > >for "session affinity" in load balancing > > I'm curious about this. If you go with a SQL database in a multiple server > box situation, don't they all have to hit the same SQL server on the same > box? Where's the scaling? Scaling is in the web servers, which tend to do a lot more than manage session data. If you need to, you can dedicate a server to doing only session data. This gives you a single point of failure, but that single point is not as likely to be overloaded as if you had one monster database server that handled all of your SQL data. (Besides, session data is short-lived and should be non-critical.) Yes, there are replicated databases, but no one that I know of does it well for active data. OTHO, if Oracle, with 20 years of experience and hundreds of developers can't do it, why should we think that we can do it in a couple of months using Python? Taking the session server idea one step further, it would not need to use a SQL database, just something that handled the consistency properly. (Hmm. Maybe there is something we could do with Python in a couple of months. Session data has some interesting characteristics that allow some optimization.) |
From: Tom S. <tom...@li...> - 2001-03-14 15:48:41
|
Terrel Shumway wrote: > BTW. Is anyone using webware in a setup that requires load balancing? Is > anyone planning to do so? Not yet, but this would be the coolest thing to add rigt now. mod_backhand and mod_director from Enhydra is some interesting stuff to look at. The first step you be a setup whre many Webware servers are running on one (or different) box(es) (using the same SQL-date) and the adapter would choose one of them. Which one is the question? Round robin, randomly, one with the lowest load (how to measure that?), ... As I shoed in the last mail how to cnofigure Zope and webware for simultaneous usage, one can easily factor out different directories to be server by other Webware instances. Pn an SMP machine you really get performance improvements by using more than one Webware instance, because of the global Python interpreter lock which is uses "many times" so to say.. -- Tom Schwaller http://www.linux-community.de |