Bug #28400
closed
CPU limits cause ajax.php to end prematurly
Added by Philipp Metzler almost 13 years ago.
Updated about 9 years ago.
Category:
Extension Manager
Description
If you run Typo3 on an account that has a CPU limit of 9 seconds and you try to "Retrieve / Update" in the "Extension Manager" in the tab "Remote Repository" the extension manager will display the message:
No update needed!
Repository is up to date.
But if you look at the error logs you will find:
Premature end of script headers: ajax.php, referer: http://www.domain.com/typo3/mod.php?M=tools_emdop
This error should be detected an a proper error message displayed to the user.
- Status changed from New to Accepted
- Target version set to 4.6.0-RC1
I had a brief look. Problem is in em_repositorylist.js
, where the call is made:
repositoryUpdate: function() {
var m = Ext.MessageBox.wait(TYPO3.l10n.localize('msg_longwait'), TYPO3.l10n.localize('repository_update'));
var index = TYPO3.EM.RepositoryCombo.getValue();
if (!index) {
return;
}
var record = this.repositoryStore.getAt(index - 1);
TYPO3.EM.ExtDirect.repositoryUpdate(index, function(response) {
...
Somehow we would have to trigger a FlashMessage, when Ext.Direct timeout occurs. But I have no clue, how to do this.
Steffen Gebert wrote:
I had a brief look. Problem is in em_repositorylist.js
, where the call is made:
[...]
Somehow we would have to trigger a FlashMessage, when Ext.Direct timeout occurs. But I have no clue, how to do this.
Ext.Ajax provides a request exception event - however since Ext.Ajax is a singleton it needs to be defined globally - it does not have a proper scope of the specific ExtDirect request.
http://dev.sencha.com/deploy/ext-3.4.0/docs/source/Connection.html#cls-Ext.Ajax
The following code catches all non parseable errors (timeouts included) in an extension of mine.
Also you can define a custom error message ;)
Ext.Direct.on('event',function(e,provider) {
if(e.result) {
if(e.result.errorMessage) {
Ext.Msg.alert('',e.result.errorMessage);
}
} else {
if(e.type == 'exception') {
Ext.Msg.alert('Server Exception:','<div style="width:100px;overflow:auto">'+e.xhr.responseText+'</div>');
}
}
});
- Target version changed from 4.6.0-RC1 to 4.6.0
I agree that a low max_execution_time is bad, but I see no way to fix this until the release of 4.6 (and it has always been this way). So I'm unsetting target 4.6.0.
To be honest, it requires some restructuring, which I doubt would go back into 4.5 as a bug fix. But let's see, when sb. has a fix for that.
- Target version deleted (
4.6.0)
The default max_execution_time in PHP is 30 Seconds, but EM mostly needs more, if he import the extensions.
Afterwards, the extensions.xml.gz is present and have a actually date and hash, so the import doesn't start again. You only get the message "No update needed! Repository is up to date."
So EM should ensure that it really imported all extensions.
The php timeout problem seems also in #17960
- Status changed from Accepted to Needs Feedback
- Is Regression set to No
Hi,
as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (6.2.9)?
We did some patches to improve the importing of extensions.
I speeded up the loading of the extension so it is 6 times faster due to better SQL commands. This was for 6.2.
Just tested with TYPO3 6.2.10 and a time limit of 4 seconds. It worked so this doesn't seem to be an issue anymore.
- Status changed from Needs Feedback to Closed
Also available in: Atom
PDF