I have a client that I set up on Plone about 9 months ago. It was a substantial amount of work moving them over to Plone, what with having to make a skin and copy all of the pages into Plone pages. It was all towards making my life easier in the long run, because, in theory, the users would be able to add their own news items and events.
For the first few months this was “sort of” working, but somewhere along the line I started having problems with Zope hanging, and hogging the processor and memory. Now it is at the point where this is happening hourly.
I have played with caching, session timeouts, and packing the ZODB, and anything else I can think of, but the site still seems to hang. The error logs are not helpful as they don’t give any indication that I can see as to what is causing the hanging.
So I decide to try to upgrade to the latest version (Plone 3 – I’m running 2.1). So I install a newer version of Python (2.4.4), and a new version of Zope (2.10), and finally I try to import and migrate one of my sites into the new instance. 2 hours of torture later I find that Plone 3 changed the way it handles its workflows and it is completely incompatible with the way that they were handled in Plone 2.5 and lower – so none of my add-on products will work (including the Forum, Ploneboard).
Well, so much for Plone 3. I guess I won’t EVER be upgrading to that one.
So what about Plone 2.5. Okay.. same deal. Installed different version of Zope (2.9.7) as recommended, then tried to import and migrate the site… But again – since Plone 2.5 changes the way it handles user accounts in an incompatible way, I need to uninstall the CAS module that I use for authentication…. Not today..
So I decide that maybe i just need to install the same version.. So I reinstall Zope 2.8.7, and Plone 2.1.4 and move the ZODB over to this new instance… It appears to be working ok for the first few minutes… however.. an hour later, it too is locking up.
So maybe it’s Python. I install Python 2.3.5 again in its own folder, then install Zope 2.8.7 on top of it, then I try to run my site on this instance…. Oh… but some of the extensions that I had compiled into my other Python 3.5 still need to be compiled in… so I compile/install PIL – seems to work ok — but then it comes to MySQL-Python so that I can access a MySQL database from Plone. This I spent 8 hours on, as there were missing libraries and header files.
Finally when I get it installed, this instance just locks up before I can even do anything…
Perhaps I’m not “smart” enough to run Plone.
I have been fed up with Plone before but keep on persisting because of all of the great features it appears to have. However, the single most important feature for me is that the site stays running. I’m at the end of my rope and really don’t know what to do at this point other than restart the server every hour until I manage to port the site back to PHP – a technology that just works!
Sounds to me like it might be a hardware problem (memory defect).
I’m not a Plone expert, having heard of it for the first time now, but random crashes sound somehow familiar 😉
I had similar problems with Plone. I decided to try Django, with great success. In fact, I suggest you try a Python framework if you did love Python but hated the fact that Plone makes it difficult to actually do stuff using Python only.
I know, don’t feed the trolls, but… 😉
You are using a beta version. In our universe, beta actually means “not production ready”.
The fact that add-on products haven’t been updated to work with the *not yet released* 3.0 version of Plone is expected.
That’s all. If there’s anything we can do to help, let us know — we’re a helpful community if you have realistic expectations. 🙂
OK.. I think I may have solved the problem of the hanging. It was a product named COREBlog that allowed comments, and likely spammers had spammed thousands of comments into the blog to the point where requesting to view the blog caused it to load all of the comments… this would lock up Zope.
It took about 15 minutes for Zope to delete the blogs (that is an indication as to just how big they were), and I am in the process of packing the ZODB.
The ZODB was 2 gigabytes with the blogs.
After deleting the blogs and packing the ZODB, it is now down to 52 Megabytes!!
Wow… keep an eye on your blogs.
Yeah, older Plone versions had security issues and were specifically targetted by spambots.
With regards to a non-breaking upgrade, have you asked the Plone mailing list/IRC channels? They really are a helpful bunch of people – and an upgrade, if possible, would be beneficial, but I feel your pain – we’ve had a few issues with Plone addins.
And kudos on updating your blog with the cause, do you know you got Reddited? 🙂
Steve,
Third-party add-on products are both the blessing and the curse of open-source platforms. 🙂
BTW, Plone 3 is not released yet, so you definitely don’t want to be upgrading a production site to pre-release software. It’s hardly fair to judge Plone by the fact that not all third party add-on developers have yet updated their add-ons for software that is still in beta!
Hi Shannah
Does that mean you are not finished with plone now 🙂 There is quite a bit of stuff on the coreblog mailing list about preventing comment spam and trackback spam getting into your coreblog2 instance. I posted a thread on what I did at http://thread.gmane.org/gmane.comp.python.zope.coreblog.english/646/focus=647
Wow. I was looking at open source site builders a couple years ago for an online communities project and considered using Plone because I had an instructor who was really a fan of it (but then again she’d never had to administrate it before.) It looks to have a lot of potential, that’s for sure.
Lame. I guess the all-in-one CMS isn’t exactly the kind of thing you can always trust to open source. 😉
Steve, are you using Apache or something as proxy in front of Plone?
If not, look into it.
Plone is limited to a wee number of connections while Apache can handle many (forked). A big request from a dial-up user gets spoon-fed slowly and keeps one of Plone’s expensive connections busy for the duration. Handing that same request off to Apache frees Plone up immediately, ready for more requests while Apache efficiently deals with it.
Wow.. I didn’t realize how much attention this post gathered. Due to the volume of spam I have been getting on my blog, I had been ignoring the comments. After finally getting around to tightening up the spam problem I discovered some great comments – some from some quite accomplished folks (e.g. Limi above).
When I first started digging into my comments today, there were over 10 thousand comments – almost all spam! I was able to knock that number down to 3000 by deleting all comments containing the word ‘v*agra’ (note I can’t even say the word here, because I have set the blog to block all posts with that word).
I think the problem is under control.
This adventure with WordPress’s comment spam serves to contrast my experience with COREBlog. Both blogs were being peppered with spam. In the case of COREBlog, it crashed Zope whenever the Blog was accessed. With WordPress, the blog and all other services on the web server continued to function without a problem.
We could jump to the conclusion, then, that Zope does not scale very well and that the LAMP architecture is more stable; but such a conclusion would be unfair and incomplete. Certainly this experience has made me much more careful about which Products I install.
It also highlights an important architectural principle that should be observed when designing Zope products: Do not allow a single object to grow arbitrarily large.
I suspect that COREBlog stores all of its comments inside the same object as its posts. This causes the posts to grow arbitrarily large, and cause problems when it needs to be loaded. A better design would have been to store each comment as a separate object and reference them from the parent post.
The possibility of a bloated object taking down the system is a little scary, though. Perhaps safeguards should be implemented to prevent this situation from occuring. Just as it is important for desktop operating systems to withstand bad processes – it is crucial for a web server to be able to survive when bad objects begin to form.
In response to some of the questions in previous comments:
1. I am using Apache as a proxy in front of Plone.
2. It is a good point that Plone 3 was in Beta. The problem of upgrading is sort of a recurring theme in my Plone experience, however. It is quite remarkable the work that the Plone team has done on the Migration tool to allow for migrations between versions. However, in my experience third-party products rarely work nice with these migrations.
In my opinion. Plone is still the most powerful and full-featured open source content management system available. However scary moments like this one have me constantly searching for alternatives.
I run Plone 3 demo site on my laptop, which incidently is one of the most miniscule configuration – Celerom M,1.5 GHz, 1 MB L2 cache, 512 MB DDR2 RAM, windows xp (tsk…tsk), I have noticed that it runs smoothly, but if you are using linux, you may have to carry out all the tasks by yourself, like editing conf files, defining Zope locations etc..
The Windows installer works fine and puts everything in-the-box..
But I agree that Plone is the simple but complex to handle CMF system..
😛