Job runs too frequently, throttled to protect the system.

Hey there, again a topic about this common issue : Job runs too frequently, throttled to protect the system.

Got this at random time, not every hour, just random time.

I’ve inspected the log in debug mode, I have 3 jobs that are launched every hour and im nearly sure the issue come from : GOOGLE MAPS GEOCODING PROCESS

Here are the two lines that tell me it come from here :

Tue Sep 24 15:00:04 2019 [30611][1][DEBUG] ----->Firing was successful:
Tue Sep 24 15:00:04 2019 [30611][1][DEBUG] ----->WTIH RESULT: HTTP/1.1 301 Moved Permanently

In the scheduler i have this in URL : url::

So maybe its an encode issue ?

The strange thing is that in the log it says that it’s a success.

Tue Sep 24 15:00:04 2019 [30611][1][INFO] Query:UPDATE job_queue
					SET `assigned_user_id`='1',`name`='Google Maps Geocoding Process',`date_modified`='2019-09-24 13:00:03',`scheduler_id`='648ef1e9-704f-96c9-e789-5d02083b48e2',`execute_time`='2019-09-24 13:00:00',`status`='done',`resolution`='success',`message`=NULL,`target`='url::',`data`=NULL,`requeue`=0,`retry_count`=NULL,`failure_count`=NULL,`job_delay`=0,`client`='CRONa0af2a63b6342f94d4a6e68c780ac405:30611',`percent_complete`=NULL
					 WHERE = 'bbda6ba9-f9be-67fa-36ff-5d8a13f5d14f' AND deleted=0

Ofc, the geocoding not work. But I found that during the debug of my main issue (Job runs too frequently) so I assume that I have some time the runs too frequently because of that.

I have tried to turn of “re launch if missed” but I still have the error log.

Hope someone can help, I’ve been doing detective thing in log for a week now, without founding a proper fix !

I’ve checked in the database, it save correctly the URL :

(‘648ef1e9-704f-96c9-e789-5d02083b48e2’, 0, ‘2019-06-13 08:25:45’, ‘2019-09-06 09:30:39’, ‘1’, ‘1’, ‘Google Maps Geocoding Process’, ‘url::’, ‘2005-01-01 09:30:00’, NULL, ‘0::/1::::::’, NULL, NULL, ‘2019-09-16 08:00:01’, ‘Active’, 1),

So its during the process that it change the URL.

And I can add that it redirect to the login page after the 301 error :

“GET /index.php?module=jjwg_Maps&entryPoint=jjwg_Maps&cron=1 HTTP/1.1” 301 - “-” “-” “-”
“GET /index.php?action=Login&module=Users&login_module=jjwg_Maps&login_action=index HTTP/1.1” 200 14404 “-” “-” “-”

So, I think I finally found my issue, the thing with this small error-log, is that it’s not specific to a job. So it will fix MY issue, but not all…
I think this error log really need to mention the job, this way we will skip that “detective” part.

I fixed the 301 error that I mention in my last post and now I don’t have the error anymore.

Before my fix I had this : /index.php?module=jjwg_Maps&entryPoint=jjwg_Maps&cron=1
But in the database its correctly saved so its during the process :

In /SuiteCRM/modules/SchedulersJobs/SchedulersJob.php

Line 555

} elseif ($exJob[0] == 'url') {
            if (function_exists('curl_init')) {
                $GLOBALS['log']->debug('----->SchedulersJob firing URL job: '.$exJob[1]);
                set_error_handler(array($this, "errorHandler"), E_ALL & ~E_NOTICE & ~E_STRICT);
		// Ici original remplacer par le mien 
                // if ($this->fireUrl($exJob[1])) {
                if ($this->fireUrl(html_entity_decode(html_entity_decode($exJob[1])))) {
                    return true;
                } else {
                    return false;

I just change : if ($this->fireUrl($exJob[1])) {

To : if ($this->fireUrl(html_entity_decode(html_entity_decode($exJob[1])))) {

I use 2 time html_entity_decode() cause it seem it has been encoded 2 times, so it fires correctly my URL without thoses ;amp thing.

In my server log it confirm it :
[30/Sep/2019:04:00:01 +0200] “GET /index.php?module=jjwg_Maps&entryPoint=jjwg_Maps&cron=1 HTTP/1.1” 200 - “-” “-” “-”

So @PGR its maybe cause of my setting that it encode it this way ? Or it is a common error for everyone but someone would saw it before me in this case… I think I need to open a github issue on this

1 Like

Keep an eye on this issue, it seems to be related

1 Like


I cannot believe that in Oct 2022 this bug still exists, but it does.

Your fix let me get it working again.