|
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
|