Public Forums 71,145 posts

[tccmike Friend tccmikeJoin date: August 2011Posts: 36Downloads:0Uploads:15 Thanks: 10 Thanked: 1 times in 1 posts]

#172300

So I figured out how to reproduce this issue today and also how to fix it for windows.
(As far as I know this problem is only on Windows using IIS w/ PHP5+ *My Linux environments have never had this issue*)

Reproduce problem:
Install on Windows 2008 R2 w/ IIS 7 or 7.5
Install PHP, MySQL, and whatever else you need to make Joomla! work
Install Joomla! 1.7+ and JA T3 framework using any quickstart or build it manually either way will work.
Then turn on the templates cache – Join, minify, compress options and out of dev mode. (doesn’t always cause the error otherwise)

Basically it would seem that when you clear the cache in the admin mode it just deletes the folder “t3-assets” which is great on a linux box where the system doesn’t lock it; however on a windows box it seems to not release the lock on the file/folder handle. then when you try to reload the website you get the site just lock and never loads and in your php error logs you get something to the effect of: file_put_contents permission denied

After you use Task Manager and End Process for all the php-cgi.exe *32 for whatever site is being tested (they will be the ones that go to 80+% CPU usage) then reload the site it works fine…

Then after some tracing you discover the root cause is that PHP 5+ doesn’t necessarily release the handles until the process is terminated.

To fix it go to the file “/plugins/system/jat3/jat3/core/cache.php” and in the “function clean ($t3assets = false)”
There are two lines in this function that say:
[PHP]@JFolder::delete ($path);[/PHP]

change them to:
[PHP]
$files = @JFolder::files($path,’.’,true,true);
foreach( $files as $file ) {
if ( is_file( $file ) )
unlink ( $file );
}
//@JFolder::delete ($path);
[/PHP]

Then it will not lockup the file on you and your issues will go away… pretty sure this would work for either box type but it does take longer to execute since it has to go through all the files but its better than the alternative on the windows box.

If there is a better way to fix this issue please let me know…

FYI I saw the FTP Server option in the code but it won’t work because of our firewall guy and how he has the DMZ configured…

-Mike

[Manos Moderator ManosJoin date: February 2014Posts: 2806Downloads:46Uploads:56 Thanks: 200 Thanked: 633 times in 576 posts]

#432073

Hi,

I am not sure but this is very interesting it’s actually a flaw on IIS or should we / you investigate of a miss configuration ?
….i know i will investigate this cause i like to struggle with those problems 😎

HAPPY NEW YEAR FROM GREECE! 😀

[tccmike Friend tccmikeJoin date: August 2011Posts: 36Downloads:0Uploads:15 Thanks: 10 Thanked: 1 times in 1 posts]

#434723

It does it on every IIS 7.5 Server I have. I don’t think it is anything to do with JAT3 coding as I have seen PHP on windows do other things similar to this ever since they went to the implicit unlock they use in the newer versions. So now it requires the PHP process to die before releasing the lock, hence why it does this:
1) clear cache
2) refresh
3) it locks and just stays (as long as this session is open and php on the server is running still it will remain locked)
4) reopen the window and type in the address for the page and it will work. (lock on the folder is gone now)

I just wanted to share what I did to fix it in my situation, it would be nice if the code checked if it was on an IIS server or Apache server and deleted it as described above instead if it is IIS, rather than deleting just the contents which it can still do for Linux just fine.

[tccmike Friend tccmikeJoin date: August 2011Posts: 36Downloads:0Uploads:15 Thanks: 10 Thanked: 1 times in 1 posts]

#435424

Just thought I would mention I just upgraded JAT3 and it has the above code commented out however the new version of JAT3 still freezes up windows IIS… just need to change one line now for windows though instead of two.

JAT3 Framework version: 1.6.0
“/plugins/system/jat3/jat3/core/cache.php”

Line 242:


241: if (is_dir($path)) {
242: @JFolder::delete($path);
243: }


Replace with:


241: if (is_dir($path)) {
242: $files = @JFolder::files($path,'.',true,true);
243: foreach( $files as $file ) {
244: if ( is_file( $file ) )
245: unlink ( $file );
246: }
247: //@JFolder::delete ($path);
248: }


The code base really does work wonderfully with this change, if possible can future releases have a switch for this or something in the configuration area so I don’t have to change this for every install on IIS?
Just a thought since it does essentially the same thing as far as clearing the cache goes but doesn’t cause that stupid lockup in windows…

[n6rej Friend n6rejJoin date: November 2006Posts: 1040Downloads:0Uploads:63 Thanks: 79 Thanked: 145 times in 90 posts]

#435432

the execution time for the windows version could be appreciably longer due to length could it not?
perhaps an environment sensing switch is needed?

[tccmike Friend tccmikeJoin date: August 2011Posts: 36Downloads:0Uploads:15 Thanks: 10 Thanked: 1 times in 1 posts]

#435450

Yes the “Big O” on mine could be a bit larger for some caches, that have a large number of individual files, however it won’t cause the next person to visit your site to have a browser lockup. The lockup is considerably worse.

You could do an environment switch using something like:


if( php_uname('s') == "Windows NT" ) {
$files = @JFolder::files($path,'.',true,true);
foreach( $files as $file ) {
if ( is_file( $file ) )
unlink ( $file );
}
}
else {
@JFolder::delete ($path);
}


I was just thinking of having a check box in the configuration and then just check if you are experiencing issues. Mostly because I believe it is an IIS w/ PHP issue so if you are running apache on windows then it may be just fine… (untested so I don’t know).

It could also be version specific… and with out a lot of testing between different versions and such I don’t know how you would determine the proper logic to do it automatically, but it would work regardless if you just do it for all windows servers.

I do know that Windows Server 2008 R2 64Bit running IIS 7.5 w/ PHP 5+ (does it with PHP 5.2, 5.3.8, 5.3.9 all tested). All installed from the MS Web Platform Installer.

Tested on 4 machines running this configuration with different specifics for external vs internal hosting and they all do it.

-Mike

[tccmike Friend tccmikeJoin date: August 2011Posts: 36Downloads:0Uploads:15 Thanks: 10 Thanked: 1 times in 1 posts]

#435464

One note I found on the PHP forum is this:

http://php.net/manual/en/function.session-start.php

<blockquote>mike at mikebird dot co dot uk 10-Dec-2006 02:34
It seems that the session file is opened exclusively.
On some occasions (Windows) I have found that the file lock is not released properly for whatever reason, therefore causing session_start() to hang infinitely on any future script executions.
My way round this problem was to use session_set_save_handler() and make sure the write function used fopen($file, ‘w’) instead of fopen($file, ‘x’)</blockquote>

That sounds a lot like what it is happening to my windows server.
Not sure how I would implement this in the JAT3 code base off hand to test if this would fix the issue though.

[n6rej Friend n6rejJoin date: November 2006Posts: 1040Downloads:0Uploads:63 Thanks: 79 Thanked: 145 times in 90 posts]

#435596

is this just a T3 issue or is it J! wide? Also, I’ve pushed it to the dev’s for their edification. We’ll see what we can do about implementing some solution. Something else the cache has perm levels set by JAEM and such… also .htacess… could this be the root cause?

[tccmike Friend tccmikeJoin date: August 2011Posts: 36Downloads:0Uploads:15 Thanks: 10 Thanked: 1 times in 1 posts]

#444580

is this just a T3 issue or is it J! wide?
Technically the root cause is PHP wide for anything that is implemented over Windows. It does it whenever I install a new extension now as well ever since I upgraded to 2.5.x.

Also, I’ve pushed it to the dev’s for their edification. We’ll see what we can do about implementing some solution.

Something else the cache has perm levels set by JAEM and such… its not the permission levels that have anything to do with it, it has to do with “File in Use” type locking.
(Some people get this same error erroneously due to windows indexing service, however that is why I intentionally have that uninstalled and the folder and all sub-folders set to not index.)

also .htacess… could this be the root cause?
-Only a problem on Windows w/ IIS7+ so .htaccess is not applicable. web.config maybe but that is set to only do the url rewrite rules all others are inherited from the server where I set most of the rules globally. (URL rewrite and such can change from one website to another.)

[n6rej Friend n6rejJoin date: November 2006Posts: 1040Downloads:0Uploads:63 Thanks: 79 Thanked: 145 times in 90 posts]

#444621

Microsoft is working with J! to make joomla very windows friendly. They’ve even gone as far as to make a “turnkey” installation available of it. I would encourage you to take what you just told me over to the joomla forums.

[tccmike Friend tccmikeJoin date: August 2011Posts: 36Downloads:0Uploads:15 Thanks: 10 Thanked: 1 times in 1 posts]

#444623

except that this is specific to the cache clearing algorithm in JAT3. the one in Joomla! seems to work fine. I really don’t have a problem at this point I just modify that line of code and continue on.

[assl Friend asslJoin date: March 2011Posts: 5Downloads:74Uploads:0]

#453328

I had the problem where <blockquote>Basically it would seem that when you clear the cache in the admin mode it just deletes the folder “t3-assets” </blockquote>. The issue was with the permissions on Windows. Having ‘Modify’ checked off for the folder allows Joomla to delete the folder and subfolders when you click Clean Cache. Once that Modify is off, my problem disappeared.

[Author]

Posts