Images on load balanced servers

Tuesday 31 May 2005 5:15:51 pm

I think you may wish to use this contribution to more closely track these modified files. <i>http://ez.no/community/contribs/hacks/php_file_logging</i>

Related Articles and Messages:

<i>http://www.ez.no/community/articles/clustering_ez_publish
http://ez.no/community/news/ez_publish_3_enterprise_setup_test
http://www.ez.no/community/forum/install_configuration/load_balanced_configuration</i>
http://www.ez.no/community/forum/install_configuration/new_ez_no_servers

//kracker

<i>Look; I can't change the way I think, And I can't change the way I am ...</i>

eminem : still don't give a ....

Member since: 2001.07.13 || http://ezpedia.se7enx.com/

Wednesday 01 June 2005 1:55:11 am

I guess what I am trying to point out is that the contribution: <i>http://ez.no/community/contribs/hacks/php_file_logging</i>

Provides a patch to the ezimagefile.php file (provided with contribution) that creates a real time log of the files created by eZ publish (ie: image variations). With this contribution you can sync the files listed in the log specifically with the sync.php script (image variations, newly added images, etc) in (close to) real time which can be used to more closely rsync between the different nodes on your server cluster.

I believe this would allow you to reach your goal. I could be wrong, I'm open to this, this is my first impression. I simply suggest testing this contribution for yourself to see if you think or see weather it will meet your own needs.
If I am wrong, you might be able to extend it to then meet your needs.

Here is the part of the code that made me think that this would work for you, the patch adds code to log files created.

Index: kernel/classes/datatypes/ezimage/ezimagefile.php
===================================================================
--- kernel/classes/datatypes/ezimage/ezimagefile.php    (revision 10945)
+++ kernel/classes/datatypes/ezimage/ezimagefile.php    (working copy)
@@ -124,6 +124,16 @@
         if ( $fileObject )
             return false;
         $fileObject =& eZImageFile::create( $contentObjectAttributeID, $filepath );
+        if ( !strpos( $filepath, "/storage/images-versioned/" ) )
+        {
+            $logFile = ini_get( 'file_action_log' );
+            if (!$logFile)
+                $logFile = "/tmp/fileops.log";
+            $fp = fopen( $logFile, "a" );
+            fwrite( $fp, "w\t" . $filepath . "\n" );
+            fclose( $fp );
+        }
+
         $fileObject->store();
         return true;
     }

//kracker
<i>Aesop Rock : Easy</i>

Member since: 2001.07.13 || http://ezpedia.se7enx.com/

Wednesday 01 June 2005 7:52:53 am

Thanks for the reply. The help is much appreciated.

There's 2 things. First, the hack described is not ideal because whatever synch method you use, if it's not realtime it's not perfect (as mentioned in the article: "his cluster setup is not ideal. If a page is visited on server A which causes an image variation to be created, e.g. the first time an article is shown with an embedded image, and server B gets a hit on the same page before the image variation has been synced from server A to B then the image shown on server B will be broken.").

So that's why I'm trying to find a better solution.

Second, I should have described my setup a bit better.
I basically have 3 servers. One is the "admin" server, and this is the only server that is used for admin. There is no user contribution or anything on the frontend, so all the content edited, or files uploaded will be done through this server.
We use rsynch to synch the storage and cache folders from the admin server to 2 "front-end" servers. These means, that when the servers get synched, the cache gets updated from the "admin" server (this usually means cache gets deleted and recreated on the front-end servers), and while this happens, the storage folders get synched to, so in theory the images would be available.
Now. What happens is, that the first hit to an article with an image, will cause something to create the image variant on that server. Then, for some reason I don't understand yet, ezPublish knows this, and when somebody hits the second server, it thinks the image variant is available in the storage folder, but it isn't.
The odd thing is, is that when you "clear all cache" from the admin interface, the image variant DOES get re-created. So clearing the cache on the "broken" server fixes the problem (this is of course not realistic). BUT, when you manually delete all cache files from the file system, the image variant DOES NOT get reacreted. So, I think there must be something set in the database as well, but I can't figure out what or where.

Ideally I would like eZPublish to ALWAYS create an image variant if it is not available in the storage folder, but I don't know where to do that.

A second possible solution would be to create the image variants when the image gets uploaded. This would work because we synch the storage folder together with the cache, so when a new article with image is available after synch, the image should be available as well.

I hope this is a bit clearer? ;)

Cheers,

Dries.