RE: [Zope] Running ZopeHTTPServer and PCGI together = a bad thing ?
-----Original Message----- From: Tony McDonald [mailto:tony.mcdonald@ncl.ac.uk] Sent: Wednesday, June 02, 1999 4:38 AM To: Zope List Subject: [Zope] Running ZopeHTTPServer and PCGI together = a bad thing?
Hi, I'm running a ZopeServer on port 9673 of a machine and have set up a virtual host using the Apache redirect rules to start up the PCGI process when someone enters the site via the virtual host route.
Hmm.. your not running these servers at the same time are you? That's bad. Only one process can open a database at any one time. Zope will *usually* catch this, unless one of those processes opens the database over a network file system with brain dead locking (in other words, NFS). If you have two processes working with a db and one is using NFS, your database will be silently corrupted.
My problem is that the information shown to the user is *different*, depending on what route they choose.
If I look at the database information for the PCGI Zope I get Database Size :: 11.3M Database Location :: /home/nnle/zope/Zope-1.10.2-solaris-2.5.1-sparc/var/Data.bbb You are running Zope version: Zope 1.10.2 (binary release, python 1.5.1, solaris-2.5.1-sparc), on Python 1.5.1 (#1, Feb 16 1999, 18:37:21) [GCC 2.7.2] on sunos5. Zope has been running (with a process ID of 24082) for 19 days 15 hours 49 min16 sec. (on this server I can only 'undo' two or three transactions)
The same data for the port :9673 Zope is Database Size :: 11.3M Database Location :: /home/nnle/zope/Zope-1.10.2-solaris-2.5.1-sparc/var/Data.bbb You are running Zope version: Zope 1.10.2 (binary release, python 1.5.1, solaris-2.5.1-sparc), on Python 1.5.1 (#1, Feb 16 1999, 18:37:21) [GCC 2.7.2] on sunos5. Zope has been running (with a process ID of 3895) for 22 days 43 min 40 sec. (on this server I can 'undo' literally hundreds of transactions).
Ouch! Looks like you have two processes running. Bad! Bad!
In addition, the Zope server is much faster than the PCGI.
Yes there is some rather expensive forking overhead that must be done to get from Apache to the Zope long running process. This is startup overhead only, once the connection gets to Zope the 'time to complete' will be identical.
I have been working on the 9673 server for a long time, and usually start up the PCGI to demo the site without using port numbers. Eventually however, I must get rid of port numbers and (presumably) use the PCGI method.
I'm really concerned that there is the discrepancy in the server and would like to get it sorted out.
Does anyone have *any* clues as to what is happening?
See the part above about 'Bad!'. ;) -Michel
cheers tone. ------ Dr Tony McDonald, FMCC, Networked Learning Environments Project The Medical School, Newcastle University Tel: +44 191 222 5888 Fingerprint: 3450 876D FA41 B926 D3DD F8C3 F2D0 C3B9 8B38 18A2
_______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope
(For developer-specific issues, use the companion list, zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )
Many thanks for the response Michel, I thought I was losing it for a time...
Hmm.. your not running these servers at the same time are you? That's bad. Only one process can open a database at any one time. Zope will *usually* catch this, unless one of those processes opens the database over a network file system with brain dead locking (in other words, NFS). If you have two processes working with a db and one is using NFS, your database will be silently corrupted.
oh......sh*t I have been running the two processes simultaneously, and I've just checked with our sysadmin...we *do* use NFS. To check on the database I did; 91 % python bbb.py -s 10 -b Data.bbb Corrupted data record at 9211505 (cOFS.Fold Corrupted data record at 11844613 (cOFS.DTML My Data.bbb is 11847812 bytes, so I guess that means I'm stuffed? Is there *any* way of getting the data out of the Database and into a 'clean' one?
Ouch! Looks like you have two processes running. Bad! Bad!
I know, I know....now :(
In addition, the Zope server is much faster than the PCGI.
Yes there is some rather expensive forking overhead that must be done to get from Apache to the Zope long running process. This is startup overhead only, once the connection gets to Zope the 'time to complete' will be identical.
Is this a fork for *every* request, eg every link I select. In that case, isn't it pretty expensive overall?
Does anyone have *any* clues as to what is happening?
See the part above about 'Bad!'. ;)
-Michel
I've used bbb.py from the Zope 2 distribution to create XML transactions for 0.. 9211505 and 11844613... 11847812 (but that still leaves 9211505..11844613 in limbo) unnh... so what are my options now? 1) Chop the database at location 11844613 (but then what about the junk at 9211505) 2) export as much as possible to .bbe files and reimport into a clean database? 3) use the bbb.py from the Zope 2 distribution to get transactions in XML (but then how do I recreate the database - bbb.py doesn't mention creation of a database)? 4) give up? ... nope, that's not an option. Zope is just so damn useful. I hate to say this, but HELP! Tone ------ Dr Tony McDonald, FMCC, Networked Learning Environments Project The Medical School, Newcastle University Tel: +44 191 222 5888 Fingerprint: 3450 876D FA41 B926 D3DD F8C3 F2D0 C3B9 8B38 18A2
Tony McDonald wrote:
Many thanks for the response Michel, I thought I was losing it for a time...
Hmm.. your not running these servers at the same time are you? That's bad. Only one process can open a database at any one time. Zope will *usually* catch this, unless one of those processes opens the database over a network file system with brain dead locking (in other words, NFS). If you have two processes working with a db and one is using NFS, your database will be silently corrupted.
oh......sh*t I have been running the two processes simultaneously, and I've just checked with our sysadmin...we *do* use NFS. To check on the database I did;
91 % python bbb.py -s 10 -b Data.bbb
Corrupted data record at 9211505
What message does it give? Does Zope come up with this data? If you copied this data to another installation (or another instance home) would Zope come up? Or is the Zope process still running? Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
At 6:32 pm -0400 4/6/99, Jim Fulton wrote:
I have been running the two processes simultaneously, and I've just checked with our sysadmin...we *do* use NFS. To check on the database I did;
91 % python bbb.py -s 10 -b Data.bbb
Corrupted data record at 9211505
What message does it give?
Thanks for the reply Jim, The message from bbb.py is 33 % python bbb.py -s 10 -b Data.bbb Corrupted data record at 9211505 (cOFS.Fold Corrupted data record at 12056388 (cOFS.DTML Zope doesn't give a message as such (I have no idea how to locate the corrupt database item through the zope interface).
Does Zope come up with this data?
I don't know how to locate the data via Zope, so I can't tell whether Zope is coming up with the data or not.
If you copied this data to another installation (or another instance home) would Zope come up? Or is the Zope process still running?
Jim
I've not copied the Data.bbb file (is this the 'data' you mean?) to another installation. I'm not running the multiple INSTANCE_HOME stuff, but will have a look at it. The Zope process is still running (and I've stopped/restarted it since then). thanks for the help, tone. ------ Dr Tony McDonald, FMCC, Networked Learning Environments Project The Medical School, Newcastle University Tel: +44 191 222 5888 Fingerprint: 3450 876D FA41 B926 D3DD F8C3 F2D0 C3B9 8B38 18A2
participants (3)
-
Jim Fulton -
Michel Pelletier -
Tony McDonald