Thomas wrote:
The question I'd like to raise to the entire list regards Zope's stability. We are running Zope integrated with Apache off FreeBSD3.2 . As far as I know, this is not such an exotic setup (probably rather common?). As Chas explained previously, Zope just suddenly died. Teodore also had the same error occur and solved it by rebooting his server.
well, we use Zope on Linux combined with apache, and at least it seems to be nearly as stable as apache/php3/mysql. we might be lucky, but the real production server runs since it's up without any significant problems. that's the good news, the bad news is that this doesn't seem to be true in every environment. our intranet server (running zope) crashes about every three or four days without an obvious reason - normally not even reproducable. as our primary webserver hasn't been affected so far we believe that this behaviour might be caused be the ongoing work that's done in our intranet. so my advice is: use a separate computer as a webserver on which you only store 'things' that have been tested very well and you won't have much trouble. but: never, never, never use the production server for daily work as it seems to become more unstable with every call to standard_error_message... don't get me wrong: i like zope and working with it, and we do a lot of things these days that couldn't be done with the tools we used before, but i'm quite aware of the fact that bleeding edge technology tends to be a bit touchy. if you keep that in mind (and perhaps set your server up in a way that you get an SMS as soon as it crashes) you will have fun while working and happy customers. regards gregor --- PBM Online Services / Artis Group newmedia concepts Gregor Ottmann Leiter Softwaredesign go@pbm.de / ottmann@artis-group.com www.pbm.de / www.artis-group.com
so my advice is: use a separate computer as a webserver on which you only store 'things' that have been tested very well and you won't have much trouble. but: never, never, never use the production server for daily work as it seems to become more unstable with every call to standard_error_message...
This is indeed a very scary thought - we initially chose to go for Zope for exactly those reasons, that we could manipulate it "live" and work in versions which are then committed. It is thus critical the we shouldn't be able to bring the site down by doing things in Zope at the same time as it is online. Comments? Also, on a side note, is there a way to do offline development of Zope, and commit those changes to the main site at a later date? I know this raises important concurrency concerns, but has it ever been considered as a part of Zope's feature set? A CVS of sorts, where you check out and in files? Regards, Alexander Limi http://mp3.no
On 12/9/99 10:15 AM, Alexander Limi at alexander@mp3.no wrote:
so my advice is: use a separate computer as a webserver on which you only store 'things' that have been tested very well and you won't have much trouble. but: never, never, never use the production server for daily work as it seems to become more unstable with every call to standard_error_message...
We'd love to have substantiated problems, unfortunately it's nearly impossible to track down "seems to be..." and "every call.." without tracebacks to understand if your actually having bizarre errors that aren't being handled correctly.
This is indeed a very scary thought - we initially chose to go for Zope for exactly those reasons, that we could manipulate it "live" and work in versions which are then committed. It is thus critical the we shouldn't be able to bring the site down by doing things in Zope at the same time as it is online. Comments?
Well, it is always possible to break something, we can't catch every single possibility. One of the biggest areas of weakness is Catalog related Versions, which can cause the Catalog to be locked, breaking the live database. This should probably be better documented somewhere. This will be a difficult one to fix, but we are working on it. I'll let Michel talk more to that issue. We've had many many Zope sites that are up for months on end, so I think some of it is also problems in development style-etc, rather than the software itself. How people approach problems can make a huge difference in stability. Unfortunately, we've been lax in trying to explain to people how you approach a problem in Zope, and how you implement stable components, as it's not the same as every other system in the world.
Also, on a side note, is there a way to do offline development of Zope, and commit those changes to the main site at a later date? I know this raises important concurrency concerns, but has it ever been considered as a part of Zope's feature set? A CVS of sorts, where you check out and in files?
It sounds so easy, but how do you do CVS on an object? What is an object? What is controlled? It's logic? It's data? Methods? If someone changes the data, should you lock the methods? We've thought long and hard about this, but we've yet to find a solution that is workable in any majority of use-cases. We're more than open to ideas to solve this. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli@digicool.com http://www.digicool.com
Also, on a side note, is there a way to do offline development of Zope, and commit those changes to the main site at a later date? I know this raises important concurrency concerns, but has it ever been considered as a part of Zope's feature set? A CVS of sorts, where you check out and in files?
Well, you can run a developoment server with an identical environmen. To update the live site, you export the relevant parts, and import them into the production server. One option anyway. -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900
Also, on a side note, is there a way to do offline development of Zope, and commit those changes to the main site at a later date? I know this raises important concurrency concerns, but has it ever been considered as a part of Zope's feature set? A CVS of sorts, where you check out and in files?
Well, you can run a developoment server with an identical environmen. To update the live site, you export the relevant parts, and import them into the production server.
This simply won't work, as we have users from everywhere that want to do changes 24/7. So the main site can't be updated from a production site, because users change the main site all the time. So unless one can update selected parts in a satisfactory way (by exporting only the relevant changes) this is no option. And I can imagine it would get messy, as one had to manually keep track of what changes are made to the test server, export those bits, and then import them on the production server. Would it be an idea to implement this in an easy-to-use way in Zope 2.2? To be able to create a "diff-file" of sorts, that can be exported into the main site, and exclude certain hierarchies, like the ones the users access? While we're at it, my own wishlist for the next version: - Better handling of inheritance in ZClasses, see my earlier post (ZClasses, inheritance & stuff, on the zope@zope.org list) - Zope should produce html/dtml in compliance with w3.org's recommendations: in all lowercase - Access to the built-in debug screens from the contol panel (in production mode or not) - An option to turn on "open in new window" as default when using the preview mode (I know, mozilla and all, but as a stop-gap solution until mozilla is stable enough to use :) (small changes that would make me happy, except for the inheritance bit, which may be more time-consuming to implement) Alexander Limi http://mp3.no (CC'ed to zope-dev, please take care when replying :)
participants (4)
-
Alexander Limi -
Bill Anderson -
Christopher Petrilli -
Gregor Ottmann