eZ Engineering update: heavy parallel publishing support

Next topic

Author	Message
Bertrand Dunogier	Wednesday 05 January 2011 12:43:50 pm Hi ! Seeing the questions I got when updating my twitter feed, I thought it would be a good idea to post an update within a tad more than 140 characters ;-) You will find on the eZ github a branch named ContentPublishingQueue. It contains a new feature for the 4.5 release that aims at fixing once and for all the LOCK wait timeout issues some have been getting with eZ publish. This error usually occurs with a heavily loaded database with many concurrent publishing processes. This also depends on the contente structure and content. For instance, very large XMLText blocks will make it more likely that this occurs: the content/publish operation is encapsulated in one large database transaction; inside this transaction, many fields are updated. Most of them are restricted to the object being published and don't set any harmful lock. A few queries, though, will affect globally shared records. The most damaging ones are ezcontentobject_tree and ezurlalias_ml. Modifying this from the bottom's up would require a LARGE rewrite. Really. It will be done anyway. But in the meantime, a solution was required. The way we ended up chosing is to make publishing asynchronous, and make all the operations go through a queue. The result is a manageable load. The queue size is 10 by default, and can be modified through content.ini. Publishing is deferred to the daemon early in the operation. The editor is sent to a new page that sends AJAX requests in order to update the operation's status. Usually, within 1 to 2 seconds, the editor is given a link to the newly published object (that's new ;-)). Under the hood, a daemon (yes, a real one, with signals and everything) monitors the queue, and spawns child processes that publish the queued objects. During the whole operation, objects awaiting publishing are visible in the pending items list, and can be viewed using content/versionview. If an approval (or any kind of workflow that defers the operation to cron) is in place, a specific message is shown to the user, offering for now a link to the content/view for his object. More informations or links are of course a strong possibility for all of these messages. Once the object has been approved, the workflow continues, and completes the publishing operation. That pretty much sums it up. This is very open for feedback ;-) Bertrand Dunogier eZ Systems Engineering, Lyon http://twitter.com/bdunogier http://gplus.to/BertrandDunogier
Nicolas Pastorino	Wednesday 05 January 2011 12:59:53 pm Ah, so that's what you've been doing lately, super diligently, sitting in front of me ? (kidding :) ) I hope some of you #ezcommunity will have installed bases where such locks happened where you can test-proof this (and get blown) ! Cheers ! -- Nicolas Pastorino Director Community - eZ Member of the Community Project Board eZ Publish Community on twitter: http://twitter.com/ezcommunity t : http://twitter.com/jeanvoye G+ : http://plus.tl/jeanvoye
Edi Modrić	Wednesday 05 January 2011 2:09:16 pm " I hope some of you #ezcommunity will have installed bases where such locks happened where you can test-proof this (and get blown) ! " I can think of a few where this should come in handy :D Great job Bertrand, sounds great to me and can't wait to test this one out! eZ Publish certified developer http://ez.no/certification/verify/350658
Andrew Duck	Wednesday 05 January 2011 3:07:04 pm This sounds very good. It will be nice to get rid of the locks, but the real nice thing I read is that approval processes will receive a message rather than just returning to the parent object. It will be nice that editors can receive a visual notification that their object won't be published immediately. Andrew Duck, Executive Director, Quiqcorp Limited eZ Certified Developer and Trainer. Member of the Community Project Board http://quiqcorp.com \| http://twitter.com/andrewduck
Damien Pobel	Thursday 06 January 2011 12:23:55 am " This sounds very good. It will be nice to get rid of the locks, but the real nice thing I read is that approval processes will receive a message rather than just returning to the parent object. It will be nice that editors can receive a visual notification that their object won't be published immediately. " This seems a great idea :-) You should open an issue for that ! Damien Planet eZ Publish.fr : http://www.planet-ezpublish.fr Certification : http://auth.ez.no/certification/verify/372448 Publications about eZ Publish : http://pwet.fr/tags/keywords/weblog/ez_publish
Bertrand Dunogier	Thursday 06 January 2011 12:55:04 am Open an issue ? Have you read the initial post, Damien ? ;-) There is such a screen already. My main concern is that interrupted operations don't return as much infos as I'd like them to. It is a bit hard to figure out why the interruption occured. We'll have to improve that. Bertrand Dunogier eZ Systems Engineering, Lyon http://twitter.com/bdunogier http://gplus.to/BertrandDunogier
Damien Pobel	Thursday 06 January 2011 1:17:22 am Yes of course ;-) I was talking about the fact that currently (and without the queue publishing system in the future I've really read correctly :)), when an object goes in an after publish workflow that do not return eZWorkflowType::STATUS_ACCEPTED it is not directly published, but the editor has no info on that because it is redirected to the parent node without any message. Cheers Damien Planet eZ Publish.fr : http://www.planet-ezpublish.fr Certification : http://auth.ez.no/certification/verify/372448 Publications about eZ Publish : http://pwet.fr/tags/keywords/weblog/ez_publish
Andrew Duck	Thursday 06 January 2011 1:33:21 am " My main concern is that interrupted operations don't return as much infos as I'd like them to. It is a bit hard to figure out why the interruption occured. We'll have to improve that. " Yes it would be nice to be able to customise return messages based on the type/status of workflow events or interruptions. Especially where you have conditional workflow events which may or may not be triggered during a given publish operation. Andrew Duck, Executive Director, Quiqcorp Limited eZ Certified Developer and Trainer. Member of the Community Project Board http://quiqcorp.com \| http://twitter.com/andrewduck
Bertrand Dunogier	Thursday 06 January 2011 2:44:11 am " " My main concern is that interrupted operations don't return as much infos as I'd like them to. It is a bit hard to figure out why the interruption occured. We'll have to improve that. " Yes it would be nice to be able to customise return messages based on the type/status of workflow events or interruptions. Especially where you have conditional workflow events which may or may not be triggered during a given publish operation. " My goal exactly. AJAX will make it a bit harder to use real overrides here, we're gonna have to figure out another way, while maintaining flexibility. Bertrand Dunogier eZ Systems Engineering, Lyon http://twitter.com/bdunogier http://gplus.to/BertrandDunogier
Matthieu Sévère	Tuesday 18 January 2011 5:55:48 am Really cool I'm recently having quite a lot of LOCK on a project. I'll try this feature as soon as I have time ! -- eZ certified developer: http://ez.no/certification/verify/346216
Matthieu Sévère	Monday 24 January 2011 5:42:20 am I have been looking at the code, that looks like very good and I love the deamon mode with signal handling. Just something I have on my mind (Maybe for a future realease) : publishingqueueprocessor and classes/contentpublishingqueueprocessor are almost not related with the "publish" task. I would be awesome to have them compatible with an handler in the run() method so that we can call every task handler we want. This way we would be able to deal with asynchronous tasks in general (and not only asynchronous publication). This asynchronous task manager could be very usefull to deal with for example synchronisation of content (push content everywhere else). Just idea :) Anyway cheers for this awesome feature ! -- eZ certified developer: http://ez.no/certification/verify/346216
Bertrand Dunogier	Tuesday 25 January 2011 2:52:06 am Thank you for the positive feedback Matthieu ! The current iteration on this feature really aims at resolving the immediate issue with content/publish generating locks. We intend to merge this with eZScriptMonitor, so that pretty much any task can be deferred this way, but it clearly won't fit in the current release. There really is a lot to be done on this feature, in any case :-) Bertrand Dunogier eZ Systems Engineering, Lyon http://twitter.com/bdunogier http://gplus.to/BertrandDunogier
Matthieu Sévère	Tuesday 25 January 2011 3:02:28 am " The current iteration on this feature really aims at resolving the immediate issue with content/publish generating locks. We intend to merge this with eZScriptMonitor, so that pretty much any task can be deferred this way, but it clearly won't fit in the current release. " Yes ! That's pretty cool :) -- eZ certified developer: http://ez.no/certification/verify/346216