Details
-
Bug
-
Resolution: Fixed
-
High
-
5.1, 5.2, 5.3-dev, 2014.03
Description
Hello,
We have an issue with 2 of our customers in eZ Publish 4.x with Cluster DFS. ( it's still true in 5.x )
Note that it's very very hard to reproduce excepted in production environment and high traffic.
We've already detected an issue identified here : https://jira.ez.no/browse/EZP-19688.
The fact is that we have sometimes some rows in the database with a mtime=0, and eZ believes the viewcache is always good, so a new publication doesn't regenerate the viewcache.
We've identified the query which is responsible, it is in the _endCacheGeneration method of kernel/private/classes/clusterfilehandlers/dfsbackends/mysqli.php
https://github.com/ezsystems/ezpublish-legacy/blob/master/kernel/private/classes/clusterfilehandlers/dfsbackends/mysqli.php#L1608
if ( !$this->_query( "UPDATE " . self::TABLE_METADATA . " SET mtime = '{$mtime}', expired = 0, size = '{$filesize}' WHERE name_hash=MD5('$filePath')", $fname, true ) )
mtime and filesize are empty, the trace is :
UPDATE ezdfsfile SET mtime = '', expired = 0, size = '' WHERE name_hash=MD5('var/plain_site/cache/content/site/2-a54e7f5dba0d9df9de22904d309754b8.cache') - cluster::mysql::_endCacheGeneration( var/plain_site/cache/content/site/2-a54e7f5dba0d9df9de22904d309754b8.cache )[1 rows, 0.001 ms]
But, theses values come from a previous query, above in the same method :
if ( !$res = $this->_query( "SELECT * FROM " . self::TABLE_METADATA . " WHERE name_hash=MD5('$generatingFilePath') FOR UPDATE", $fname, true ) ) { $this->_rollback( $fname ); // @todo Throw an exception return false; } $generatingMetaData = mysqli_fetch_assoc( $res );
I think this query return an empty array (generatingMetaData) in the mysqli_fetch_assoc.
Then, the code enter in the "else" of this condition :
// the original file does not exist: we move the generating file $res = $this->_query( "SELECT * FROM " . self::TABLE_METADATA . " WHERE name_hash=MD5('$filePath') FOR UPDATE", $fname, false ); if ( mysqli_num_rows( $res ) == 0 )
And in this "else", we are in the query we've detected.
UPDATE ezdfsfile SET mtime = '', expired = 0, size = ''
What is the good correction, do we have yo call the rollback ?
++
Note: we already have to solution, I'm going to create the PR and comment this ticket.
Attachments
Issue Links
- links to
