eZ Community » Forums » Developer » eZ Engineering update: heavy parallel...
expandshrink

eZ Engineering update: heavy parallel publishing support

eZ Engineering update: heavy parallel publishing support

Wednesday 05 January 2011 9:43:50 pm - 12 replies

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 blunk.gif Emoticon

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 blunk.gif Emoticon).

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 blunk.gif Emoticon

Wednesday 05 January 2011 9:59:53 pm

Ah, so that's what you've been doing lately, super diligently, sitting in front of me ?

(kidding happy.gif Emoticon )

I hope some of you #ezcommunity will have installed bases where such locks happened where you can test-proof this (and get blown) !

Cheers !

Modified on Wednesday 05 January 2011 10:03:01 pm by Nicolas Pastorino

Wednesday 05 January 2011 11: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 big-smile.gif Emoticon

Great job Bertrand, sounds great to me and can't wait to test this one out!

Thursday 06 January 2011 12:07:04 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.

Thursday 06 January 2011 9: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 happy.gif Emoticon You should open an issue for that !

Thursday 06 January 2011 9:55:04 am

Open an issue ? Have you read the initial post, Damien ? blunk.gif Emoticon

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.

Thursday 06 January 2011 10:17:22 am

Yes of course blunk.gif Emoticon

I was talking about the fact that currently (and without the queue publishing system in the future I've really read correctly happy.gif Emoticon), 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

Thursday 06 January 2011 10: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.

Thursday 06 January 2011 11: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.

Tuesday 18 January 2011 2:55:48 pm

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 !

Monday 24 January 2011 2:42:20 pm

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 happy.gif Emoticon

Anyway cheers for this awesome feature !

Tuesday 25 January 2011 11: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 happy.gif Emoticon

Tuesday 25 January 2011 12:02:28 pm

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 happy.gif Emoticon

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from