Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-24763

"*.generating" files are accumulating in the 'ezdfsfile' table

    XMLWordPrintable

    Details

      Description

      In an environment comprised of eZ Publish 4.7 (fully patched) with ezoracle + Oracle DB, and set up in DFS cluster mode, it is necessary to kill database processes regularly because they are locked exceeding 900 seconds. The issue seems to be a consequence of the fact that "*.generating" files, which are temporary in nature, are in fact accumulating in the 'ezdfsfile' table when images are uploaded.

      There are no relevant errors in the error log, but cluster.log contains many entries like this:

      [ Aug 26 2015 16:39:31 ] An error occured starting cache generation on 'var/ezwebin_site/storage/image/.../.../test_image.jpg.generating'
      [ Aug 26 2015 16:39:31 ] An error occured starting cache generation on 'var/ezwebin_site/storage/images/.../.../.../test_image.jpg.generating'
      ...
      

      The customer believes this is what is happening:

      "
      1) user views page that needs the creation of an image alias

      https://github.com/ezsystems/ezpublish-legacy/blob/master/lib/ezimage/classes/ezimagemanager.php line 866
      $convertHandler = eZClusterFileHandler::instance( $sourceMimeData['url'] );

      which calls

      https://github.com/ezsystems/ezpublish-legacy/blob/master/kernel/private/classes/clusterfilehandlers/ezdfsfilehandler.php line 1287

      $ret = self::$dbbackend->_startCacheGeneration( $this->filePath, $generatingFilePath );

      if the database is having a problem for some reason and throws an non-standard error code, we end up here

      https://github.com/ezsystems/ezoracle/blob/master/clusterfilehandlers/dfsbackends/oracle.php line 1502

      // @todo Make this an actual error, maybe an exception
      return array( 'result' => 'error' );

      --as you can see from the comment, it looks like this code was never properly finished!

      When that array is returned to the calling function, we end up here
      https://github.com/ezsystems/ezpublish-legacy/blob/master/kernel/private/classes/clusterfilehandlers/ezdfsfilehandler.php line 1307

      // unhandled error case, should not happen
      else

      { eZLog::write( "An error occured starting cache generation on '$generatingFilePath'", 'cluster.log' ); return false; }

      Which puts us here

      https://github.com/ezsystems/ezpublish-legacy/blob/master/lib/ezimage/classes/ezimagemanager.php line 957

      // we were not granted file generation (someone else is doing it)
      // we wait for max. $remainingGenerationTime and check if the
      // file has been generated in between
      // Actually, we have no clue if the generated file was the one we were
      // looking for, and it doesn't seem possible to RELOAD the alias list.
      // We don't even know what attribute we're using... CRAP
      else
      "

      Further analysis has revealed that the Oracle DB issues that cause the problem in the first place are related with deadlocks (error 60). The error thrown by Oracle in https://github.com/ezsystems/ezoracle/blob/master/clusterfilehandlers/dfsbackends/oracle.php that causes the infinite loop (serialized in the variable $this->error from line 1495) is this:

      a:4:
      {s:4:"code";i:60;s:7:"message";s:55:"ORA-00060: deadlock detected while waiting for resource";s:6:"offset";i:0;s:7:"sqltext";s:264:"INSERT INTO ezdfsfile ( name, name_hash, scope, datatype, mtime, expired ) VALUES('var/ezwebin_site/storage/images/.../.../1801323-2-eng-US/test_image.jpg.generating', 'a19f9bb6614e75b2b40353945187ffde', '', '', 1441053790, 0)";}
      

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              mmarsiglio Mark Marsiglio
            • Votes:
              0 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: