eZ Community » Forums » Developer » Are your content updates not showing...
expandshrink

Are your content updates not showing sometimes? Could be this view cache issue.

Are your content updates not showing sometimes? Could be this view cache issue.

Monday 24 September 2012 7:53:06 pm - 5 replies

Hi,

our clients often complain about content updates that are not visible on the public site. The problem was hard to track down because it seems to resolve automatically after some time and it only happend on a very un-regular basis. One of those problems you really don't want to have...

But we finally found a way to reproduce it:

1) On your public site, load one of your articles (any content node would work)
2) Use Apache Benchmark to have constant requests to that article:
ab -c 2 -n 10000 http://localhost/public_site/path/to/article

3) During the "stress" test, go to your admin UI and make content changes to that article
4) Stop the "ab" process
5) On your public site, reload the article - you won't see your content changes. It will show the old version

We've done that test on ezp4.5 but most likely 4.6 and 4.7 are affected as well.

We identified the problem in the kernel code. Basically, ezp is marking a cache file (content view cache) as expired and then executes the content updates in the database. It's the wrong order and you likely run into following race condition:

1) Editor updates article and hits "Send to publishing"
2) "Send to publishing" will expire view cache
3) public site requests the article and build new cache file based on old content in the DB
4)  "Send to publishing" will execute the content updates in the DB

So let's fix the order and expire the cache after the new content is the DB. Basically, that is already the case. If you look at the "publish" operation (kernel/content/operation_definition.php). The operation step "clear-object-view-cache" comes after "set-version-published", "set-object-published" etc etc. That's good. But the problem is that all operations are wrapped inside a DB transaction. That causes all DB queries getting executed after the "publish" operation has finished.

It's not so easy to fix. Updating a content object needs to use DB transaction to insure that in case of problems the DB is left in a consistent state. But during a DB transaction you cannot mark cache as expired. I'll think about it a bit more, you probably want to split up the "publish" operation into DB updates and other operation steps. Then have all DB updates wrapped inside a DB transaction. Any suggestions?

Tuesday 25 September 2012 12:44:42 pm

Absolutely brilliant post, Philipp.

Plz open a bug in the issue tracker.

Just one question: is this website a plain or a clusterized one?

The results might be quite different in the two cases...

In fact I think that the problem stems from the fact that the clear-object-view-cache step in the "publish content" transaction actually touches an external resource, i.e. it uses the filesystem for "clearing-the-cache". And the filesystem operation is not held waiting until the transaction is committed, but "committed to disk" immediately.

It's not a big change from your description of the problem, but you might want to reorder your timeline to:

1) Editor updates article and hits "Send to publishing"

2) "Send to publishing" will execute the content updates in the DB, but the transaction keeps the changes invisible to all other web pages / php processes

3) "Send to publishing" will expire view cache. Caches on disk are immediately removed

4) public site requests the article and build new cache file based on old content in the DB

5) "Send to publishing" transaction is committed and new content is available in the db to everyone

 

Pushing cache expiration to happen just after the db transaction has been committed is something I have been advocating for a while now, but it's not something for the faint of heart.

I wonder if async publication suffers from the same problem...

Also the more you put events in your workflows, the more the window for stale-content-generation gets longer, unless workflow events take place outside of transaction...

Modified on Tuesday 25 September 2012 12:59:38 pm by Gaetano Giunta

Tuesday 25 September 2012 4:13:50 pm

We can reliably reproduce this problem on both a standard eZ Publish setup and an eZ DFS cluster setup.

Sunday 30 September 2012 10:29:49 am

The cluster setup uses the DB to expire a cache file. Still, I think it is not part of the publish DB transaction because it is a 2nd DB connection (I think) -- at least, it's a different DB. That's why you probably run into the same issue.

I like the idea of the ez publish operations. It breaks down more complex tasks (like the publishing tasks) into its core operation steps. The implementation could be more object orientated - still the concept is nice.

In our case, the publish operation is a flat list of operation steps. But I think it would be better to use a simple tree structure:

- set-version-pending
- send-to-publishing-queue
- update-section-id
- pre_publish
+ publish-update-content
    - copy-translations
    - set-version-archived
    - loop-nodes
    - set-version-published
    - set-object-published
    - publish-object-extension-handler
    - remove-old-nodes
    - attribute-publish-action
    ...
- clear-object-view-cache
... 

It should be straight forward to implement this: Group all DB relevant steps into a new operation "publish-update-content'. Remove those from the existing "publish" operation. Add a new operation step to the "publish" operation "publish-update-content-step" which will call the new "publish-update-content" operation. Then you can wrap all DB relevant steps into a transaction and exclude other operations steps from it.

 

 

 

 

 

 

Monday 22 October 2012 5:47:19 pm

Hi,

I think i am having the same problem in ezpublish community 2012.1 with ezoracle and cluster db. Did you submit a bug report so i can track the proposed patch ?

Thanks in advance

Regards

Wednesday 24 October 2012 9:15:33 pm

https://jira.ez.no/browse/EZP-19660

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from