Hi Thomas, as far as I can see, all classes except oxutils, oxsupercfg, oxutilsobject and oxconfig seem to be put into this cache file. At least in OXID eShop 4.4.8, I'm not sure about the 4.5 versions.
There actually seems to be some file locking code (in the _lockFile() method in core/oxutils.php), and I noticed that there is a branch where the file gets truncated. That might be the cause for the empty files you experience - maybe the file gets truncated, but fails to get locked and written afterwards… I was too lazy to check all of the code, so I'm not sure if this is actually an error or a normal condition. The php function "flock" seems to be used there. You might want to check the php manual page: http://php.net/flock There's some warnings there that this function might not work under certain conditions, e.g. in some multithreaded servers. If the file is empty, then the class path will be determined normally, by checking various directories for a file that matches the class name in lower case. However, if I remember correctly, we deliberately switched off this class path cache in two or three shops of our customers back then, because they experienced errors where mangled code from that file would appear in the fronted (when the file got corrupted). I'm not sure right now which shops that were, maybe Andreas remembers. Chances are that you are hosting those shops, so you might want to check the core/oxfunctions.php and search for the text "class_file_paths". If the lines where the file is included or created are commented out, then this might be our fix from back then ;-) Cheers, Robert Am 24.11.2011 um 16:46 schrieb Thomas Lohner: > Hi Robert, > > thanks, i guess you're right. > > I'll talk to the customer or maybe to oxid ;-) > > imho the way this is implemented right now is broken, it might also be > considered as a bug because it may break multi-server setups. > > This file should only change when adding or removing modules, right? All this > core stuff is kind of "static". There has to be a smart way of prerendering > this file. > > And btw. do you know why this file is empty in some of our shops? > > cheers > > -- > > Thomas Lohner > > https://www.xing.com/profile/Thomas_Lohner > > http://www.facebook.com/SysEleven > > http://www.syseleven.de > > SysEleven GmbH > Umspannwerk - Aufgang C > Ohlauer Straße 43 > 10999 Berlin > > Tel +49 30 233 2012 0 > Fax +49 30 616 755 50 > > > Firmensitz: Berlin > Registergericht: AG Berlin Charlottenburg, HRB 108571 B > Geschäftsführer: Marc Korthaus > > > > Am 24.11.2011 um 14:21 schrieb Robert Rosendahl: > >> Hi Thomas, >> >> we've had some trouble with this file a while ago with some of our >> customers, because - like you already stated - the file got corrupted, >> apparently by different worker threads writing to it at the same time. The >> result was file that was no valid php script anymore and resulted in the >> shop webpage showing an empty page with just a bit of mangled php code from >> the corrupt file. >> >> It happened rarely, but too often to tolerate, so we edited the core cache >> class of the shop to prevent this file from being written. We didn't see any >> adverse performance effects, but we didn't really measure it - it just >> didn't feel any slower without the file ;-) >> >> Anyway, I'm not sure whether the effect of getting a corrupted >> *_class_file_paths.php has been addressed by the OXID developers in the >> meantime… >> If you want to disable that feature you might want to take a look into >> core/oxfunctions.php. I believe the class_file_paths stuff is in the >> oxAutoload() function. I think there are two places - one where the file is >> included if present and one where it is created or added to (if a class is >> loaded that isn't in the cache already, then the cache file is updated to >> contain the new class path). >> >> If you can somehow measure the performance with and without class path >> caching it might be an interesting result for others, too, i believe, since >> you're hosting shops with lots of traffic. If there isn't any noticeable >> performance gain in that cache then it might make sense to offer an option >> in the shop config for switching it off. I guess the performance gain would >> also depend on the system configuration (e.g. fast or slow file storage >> access etc.). >> >> Cheers, >> Robert >> >> >> Am 24.11.2011 um 11:25 schrieb Thomas Lohner: >> >>> Hi, >>> >>> what is this file for exactly? >>> >>> tmp/oxeec_class_file_paths.php >>> >>> I guess it's some sort of mapping classnames to the php file of that class, >>> to be able to include them "faster"? >>> >>> I'm curious because I see this file empty in some of our oxid installations >>> and not empty in others. >>> >>> In any case this file is rewritten every few seconds. This is very bad >>> because this behavior prevents sharing the tmp-dir in a network file >>> system. if two servers try to write this file at the same time, which will >>> happen quite often with high traffic, the file will be locked or even >>> corrupt at worst. >>> >>> So, what does it do? How can i prevent it from being rewritten so often? >>> >>> >>> cheers >>> >>> -- >>> >>> Thomas Lohner >>> >>> https://www.xing.com/profile/Thomas_Lohner >>> >>> http://www.facebook.com/SysEleven >>> >>> http://www.syseleven.de >>> >>> SysEleven GmbH >>> Umspannwerk - Aufgang C >>> Ohlauer Straße 43 >>> 10999 Berlin >>> >>> Tel +49 30 233 2012 0 >>> Fax +49 30 616 755 50 >>> >>> >>> Firmensitz: Berlin >>> Registergericht: AG Berlin Charlottenburg, HRB 108571 B >>> Geschäftsführer: Marc Korthaus >>> >>> >>> >>> >>> _______________________________________________ >>> dev-general mailing list >>> [email protected] >>> http://dir.gmane.org/gmane.comp.php.oxid.general >> >> _______________________________________________ >> dev-general mailing list >> [email protected] >> http://dir.gmane.org/gmane.comp.php.oxid.general > > > _______________________________________________ > dev-general mailing list > [email protected] > http://dir.gmane.org/gmane.comp.php.oxid.general _______________________________________________ dev-general mailing list [email protected] http://dir.gmane.org/gmane.comp.php.oxid.general
