Project

General

Profile

Actions

Bug #15642

closed

Extension manager maximum execution time of 30 seconds exceeded

Added by Kari Salovaara over 18 years ago. Updated over 17 years ago.

Status:
Closed
Priority:
Should have
Category:
Extension Manager
Target version:
-
Start date:
2006-02-16
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.0
PHP Version:
4
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Everything went OK in installation T3 4.0 beta3.
Environment RHEL 3 clone (Tao) PHP 4.3.2
SERVER_SOFTW: Apache/2.0.46 (Tao Linux) MySQL 3.23.58

I wanted to download ter_update_check extension;
- extension manager settings > set, OK
current list -> retrieved/updated, OK
then I put ter_update_check into List or look up extensions
and clicked Look up, result;
Fatal error: Maximum execution time of 30 seconds exceeded in
/home/4.0b3/typo3_src-4.0beta3/typo3/mod/tools/em/class.em_xmlhandler.php
on line 111

Error repeatable with any extension
(issue imported from #M2587)

Actions #1

Updated by old_webbo over 18 years ago

I also received a similar timeout when accessing the Extension Manager for the very first time. Notes from my investigation are below but it would seem that PHP takes longer to retreive the data because the response is gzip encoded?


I just installed beta3 having previously been using beta2 OK.

I completed a fresh install but the Ext. Manager is "hit-and-miss" in regards to responsiveness.

In my PHP error log I see:

[22-Feb-2006 10:43:28] PHP Fatal error: Maximum execution time of 30 seconds exceeded in c:\documents and settings\Steve\workspace\typo3 4.0 beta 3\html\t3lib\class.t3lib_div.php on line 2120

which relates to:

return file_get_contents($url);

I'm not behind a proxy and therefore have no need for curl. I did a bit of dirty debugging and it seems to be a problem retreiving:

http://repositories.typo3.org/mirrors.xml.gz

I can retreive this in my browser manually so I know the content is there. Furthermore, I created a simple test PHP file:

echo file_get_contents("http://repositories.typo3.org/mirrors.xml.gz");
?>

This produces the same problem? If I use http://www.google.com/ as the URL it works as you would expect.

Environment: Win XP, PHP 5.1.1 & Apache 1.3

Actions #2

Updated by Karsten Dambekalns over 18 years ago

webbo, your problem is a different one. When simply looking up extensions no connection to the TER2 is made. So the problem this bug report is about has to do with parsing the XML (mostly) and your problem is simply strange.

Because AFAIK the time PHP is waiting for input (from the network in this case) is not taken into consideration when it comes to checking the max execution time. And if your PHP isn't able to decompress the gz file within 30 seconds, you should seriously consider buying new hardware... :)

Actions #3

Updated by Karsten Dambekalns over 18 years ago

Ah, I just checked this with a max execution time of 10 seconds and it works just fine. In fact it takes less than 2 seconds until I actually see the result.

(Environment: Debian GNU/Linux, Apache 1.3, PHP 5, Pentium M 1.5GHz, 1GB RAM)

Actions #4

Updated by old_webbo over 18 years ago

OK, I guess my error is not related to XML parsing, more down to decompressing the file.

Maybe it's a local configuration issue, it's just my home PC so far I was testing on but still pretty powerful (AMD 3200+, 1GB, XP SP2).

Actions #5

Updated by Karsten Dambekalns over 18 years ago

Hi Kari, is this still an issue with the latest RC? Thanks.

Actions #6

Updated by Kari Salovaara over 18 years ago

I'm sorry I have not time to test with RC3 but in RC2 if I want to list whole repository it gives me the message 'Fatal error: Maximum execution time of 60 seconds exceeded in /home/4.0RC2/typo3_src-4.0rc2/t3lib/class.t3lib_div.php on line 898'

If I find some time I can install RC3, but as the original roadmap of 4.0 and my own workmap have started to live separate ways 3 months ago it's difficult to find time any more as I have to study other applications.

Actions #7

Updated by Kari Salovaara over 18 years ago

So the RC3 vanished and there was born final 4.0 version. I have to regret that the situation still exists. After updated the extension list (unsupported = on); The extensions list has been updated and now contains 1546 extension entries. I want to list all extensions, so selection field is empty and Look Up button pressed.
Fatal error: Maximum execution time of 60 seconds exceeded in /home/4.0/typo3_src-4.0/typo3/mod/tools/em/class.em_index.php on line 4848

Then I tested using keyword 'nomad' it took 59.487 secs to first byte on screen 1 min 2.122 secs to complete, 53.62 kb and 24 requests to get Urban Nomad template to screen so that I can download it. Then it gets over 1 min. to doownload that about 53 kb. Then I wanted to install, I get warning messages / Dependency Error:
The running TYPO3 version (4.0) is higher than allowed (0.0.3)
The running PHP version (4.3.2) is higher than allowed (0.0.3)

Ok, they are ignored. And Urban Nomad extension installed.

Testing environment is:
Environment RHEL 3 clone (Tao) PHP 4.3.2
SERVER_SOFTW: Apache/2.0.46 (Tao Linux) MySQL 3.23.58
Typo3 4.0, clean and fresh installation (allthough much slower than 3.8.1)
2Mb ADSL connection. My server doesn't have any other processes that for serving this Apache/PHP/MySQL. I'm testing in home office network, lines 100 Mb and workstation is Intel Dual Core 2 Gb RHEL4 machine no other processes than browser.
Other older Typo3 installations working fluently and much quicker.

Actions #8

Updated by Tristan Knapp about 18 years ago

I have this error as well on a Windows Box. The gzip implementation under Windows seems not to be the greatest. (PHP 4.3.8)

This "bug" manifested itself further in saying that the extensions were not changed (or up to date - don't remember the exact wording - since the extensions.xml.gz was already downloaded) - but at the same time having an empty extension list, since PHP timed-out during the gzip.

Might want to consider changing the code to check for a successful install of the extensions list and not just if the extensions.xml.gz hasn't changed!

Actions #9

Updated by Karsten Dambekalns over 17 years ago

Since I could never reproduce this, and the way the extensions.xml.gz file is processed changed completely for 4.1, I resolve this one.

There probably won't be any far-fetched fixes for 4.0.x, anyway. If this is really caused by the gzip-handling being so slow, I'd consider this a bug in PHP...

Actions

Also available in: Atom PDF