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

Reply via email to