Tag Archives: timeout

How to Increase Sencha Ext.getStore Timeout behaviour Tips, Tricks and Tutorials 27 NOV 2014

I encountered a problem the other day where my AJAX loaded store kept failing to load when calling the native Ext.getStore() function. Chrome’s handy Developer Tools indicated that the request to the store URL was being cancelled, indicating that the AJAX request was in fact timing out.

However, Sencha’s documentation didn’t make it very apparent as to how to change the Ext.getStore() timeout behaviour, which is why I’m noting it down here in this post.

As it turns out, you can in fact set the timeout value when you define your store, by adding a ‘timeout’ value to the proxy params in your store definition.

As is the norm, the timeout is in milliseconds, meaning that if you want to set a timeout value of 60 seconds, you need to set “timeout: 60000”.

Here is an example store with the extended timeout config value added (hint: it is just after proxy->type:’ajax’):

Ext.define('KineticaDistell.store.survey.SurveyComplete', {
    extend: 'Ext.data.Store',
    alias: 'store.surveyComplete',
    requires: [
    config: {
        autoLoad: false,
        model: 'KineticaDistell.model.survey.Survey',
        storeId: 'SurveyComplete',
        proxy: {
            type: 'ajax',
            timeout: 60000,
            url: touchwork.SERVICE_URL +  '/survey/survey.php',
            reader: {
                type: 'json',
                rootProperty: 'data'
            extraParams: {

Worked a charm for me.

sencha touch logo

Force Your Script to Run Longer than Maximum Execution Time CodeUnit 08 MAR 2010

I have to process some large CSV files that generate a lot of SQL statements that need to be executed. Naturally, trying to parse any of the files almost always results in my script spitting back that horrible maximum execution time exceeded error message, even though I’ve adjusted the maximum execution time setting in the php.ini file to as large as I dare go.

So how does one go about forcing a script to stay alive infinitely until it eventually finishes its job?

(Note: You really don’t want to apply what follows to an infinite loop snippet of code!)

Well, PHP does hand us the nifty set_time_limit() function that basically restarts PHP’s built in timeout counter, setting it to zero and then changing the new timeout value to the number of seconds specified in the function call. So for example, if the timeout default is 30 seconds and you call set_time_limit(20) 25 seconds into script execution, the script will now be able to run 45 seconds before timing out.

Now calling the function with a seconds parameter of zero is said to remove the time limit altogether, though in practice you may find that this doesn’t always work exactly how it should.

If for example your long-running script is based on a long loop operation, the easiest way to ensure your script doesn’t time out is to call the set_time_limit function with a specified timeout duration of say 20 seconds for each and every loop iteration.

This will in essence keep resetting the timeout counter and extending the maximum execution time, thus resulting in a script that has a potential to run just about forever! :)

[Unless of course you are running your script under II7 on a Windows Server 2008 machine where you’ll have to adjust some additional Windows Environment parameters! Something to note though is that this function won’t work if you are running PHP in SAFE mode. Unfortunately there doesn’t seem to be a workaround for this instance! :( ]

Related Link: http://php.net/manual/en/function.set-time-limit.php

WordPress Fix for Schedule Missed Posts CodeUnit 23 DEC 2009

After upgrading successfully to WordPress 2.9 the other day, I was mortified to find that all of a sudden all of my scheduled posts were being missed one after the other, and the only solution to actually force publish them was to hit the Quick Edit option on the posts listing page and change the each post’s status to published.

Needless to say, this is rather unacceptable.

Thankfully though, there is a fix for this particular problem, one that doesn’t involve installing a new plugin but rather depends on you editing one of WordPress’ internal files.

Now if we ignore the fact that your web host has suddenly and inexplicably gone and disabled your WordPress cron, we can assume that the problem lies in the cron (or scheduled task if you are from the Windows world) itself. As you might have noticed, WordPress seems to be getting slower and slower with each release, which is pretty natural when you think about just how much extra bells and whistles the developers keep having to throw at it in order to keep the ravenous horde that are its followers happy.

However, this could be exactly where the problem lies. If you go and locate the WordPress internal file /wp-includes/cron.php, opening it up and running a search for wp_remote_post should bring up a line looking something like this:

wp_remote_post( $cron_url, array(‘timeout’ => 0.01, ‘blocking’ => false, ‘sslverify’ => apply_filters(‘https_local_ssl_verify’, true)) );

(Hint: it’s around line 229 in a standard WordPress 2.9 config file)

If you look closely at the function call being carried out, you’ll notice that a timeout value of 0.01 seconds is being passed to the function, which is coincidentally exactly where the problem lies – the remote post is being adjudged to have timed out and thus aborted before it could actually run its job properly!

So the solution?

Well it is a simply matter of increasing that relatively small number of 0.01 to something more generous, like 20 seconds for example, meaning that the updated string should now look like this:

wp_remote_post( $cron_url, array(‘timeout’ => 20, ‘blocking’ => false, ‘sslverify’ => apply_filters(‘https_local_ssl_verify’, true)) );

Obviously you then need to save your changes and upload the saved file back to the server in order for it to be activated.