Skip to main content
R
raZorTTZ
Inspiring
October 29, 2013
Question

Strange Scheduled Task (Quartz) behaviour CF10

  • October 29, 2013
  • 4 replies
  • 10252 views

Hi,

I'm running ColdFusion 10 Enterprise on a RHEL 6 server and have come across an intersting behaviour in relation to the scheduled tasks we have setup.

We noticed that after a reboot of our ColdFusion server that the scheduled tasks weren't running correctly.

When I looked in the http.log file I could see that it was trying to execute the correct template

"Information","DefaultQuartzScheduler_Worker-9","10/25/13","07:18:16",,"Starting HTTP request {URL='...', method='get'}"

But the request never appears to be completed. When a task successfully runs you would expect to see a completed line as well in the http.log file

"Information","DefaultQuartzScheduler_Worker-9","10/25/13","07:18:21",,"HTTP request completed  {Status Code=200 ,Time taken=4896 ms}"

For some reason after the server reboot the task is triggered, but it never runs and never shows as being complete.

I was playing changing settings in the scheduled task and checked the Save output to a file

One other thing I noticed was that the catalina task (check for update/hotfix) would execute and return while the other tasks (quartz) wouldn't.


Has anyone seen anything similar or have any suggestions? For now i'll just make sure my tasks all output to a file, but if there was a way to fix it I would much prefer to do that.

Thanks

Simon

This topic has been closed for replies.

4 replies

Y
yze
Inspiring
October 13, 2017

In my case the scheduled task run twice within some milliseconds (sometimes the exact millisecond!)

Then I logged IP number and the duplet tasks was run from another IP.

Turned out our internet service provider had some redundat server set up that had kicked in, and somehow the CF instance continued to run, even after our primary server kicked in again.

I put this code in some of my scheduled task, that really helped me!

<cflog file="myTasks" text="#GetCurrentTemplatePath()# Tickcount:#GetTickCount()# userAgent:#cgi.HTTP_USER_AGENT# IP:#cgi.REMOTE_ADDR#">

Then you go to CF Admin and find your myTasks.log at "Log files". Check that IP

M
Mindframe
New Participant
June 25, 2015

Hi All,

I didn't take the time to read everyone's response in here, but here's the deal:  On windows servers CF10 has a major bug in the cron job stuff - ie, scheduled tasks.  If you name your task with a space or a dash or anything other than a..z it will corrupt the file.  Once corrupted, it takes nigh an act of God to get it back working.  To do that, you must turn off coldfusion - the service MUST be stopped.  Then you can edit the neo-cron.xml file and remove everything but the top and bottom part of it with the length=4 stuff and inside that block clear it all out.  (essentially a baseline xml file).  Once that is done (and cf is still OFF), delete the neo-cron.bak file if it exists.  You will now only have your new clean neo-cron.xml file in there.  Start the cf service.  You should now be able to get back into CF Admin.  If you go to the scheduled tasks page and you get an error, then your "clean" version of your neo-cron.xml file isn't correct.  Stop CF, edit, Start & test.  Then, tell everyone not to ever put any tasks or group names in there with spaces and such.  I basically name my tasks:  ClientNameGenerateSiteMap for example. Seriously, Adobe, how did this get past your testing?  Such an obvious bug.  (bug not solution).


Good luck. 

BCfromMD
BCfromMD
New Participant
May 12, 2015

Simon,

I’m quite a bit late to this post, but my organization had what appeared to be the same issue that you were experiencing. We were specifying the proxy server and port on each of our scheduled tasks. They would work fine until either the ColdFusion service was restarted or the server was restarted. Once that happened, none of our jobs would run. We would then go into each job manually – like you – and submit the jobs and they would begin to run fine. That is, until the next restart.

What we discovered to correct this is a simple fix. Go into ColdFusion Administrator and under Server Settings/Java and JVM, you will see an area called JVM Arguments. You need to add the following to the arguments:

-Dhttp.proxyHost=111.222.333.444

-Dhttp.proxyPort=1234

Make sure that you don’t forget the beginning dash and you put in your server’s IP address and port. Save the settings and restart the ColdFusion service.

I hope this helps someone – it took quite a while to figure this one out.

Barry

A
Anonymous
October 30, 2013

Hi

I have seen something very similar to this. However, in my case the reason seems to be that CF10 does not obey HTTP proxy commands via jvm.config. You have to specifically set your proxy server for every scheduled task.

Also, I noticed that the scheduled tasks screen will not work correctly in CFIDE if you access it from an external IP address, even if you enable that IP address to have CFAdmin access.

R
raZorTTZAuthor
Inspiring
November 1, 2013

Hi Pat

I had a similar problem with tasks needing the proxy address and port added to them.

Out of interest what were the arguments you tried in the jvm config for the proxy?

Cheers,

Simon

R
raZorTTZAuthor
Inspiring
December 24, 2013

Interesting, Simon.

So do you really mean that simply “saving” the task causes it to start running? Or do you mean that you can save it and THEN execute it, whereas if you try to execute it before doing an edit/save, it fails to run when you manually try to execute it? I don’t see how saving an edit of a task would start it running.

And are you also saying that when you save it that way that then the task will run at whatever date/time it’s scheduled? At least as long as there is not a restart of CF?

As for your observation that it could be related to the save, and a potential change in the file, I saw your subsequent note saying that the neo-cron.xml file “looks fine”, but how about saving a copy of the file after a restart, then make a change, and then compare the file. Maybe there is something you’re not seeing that does differ. That said, comparing neo xml files is tough because they are WDDX-format XML which has no order within elements, let alone between them.

The connection timeout is indeed interesting, and that along with the request never showing up in FR or the access log does indeed seem to suggest it’s never really being executed. That said, I’d still propose you may want to look at the request that tries to run the scheduled task to see when it runs how long it takes, which may give a clue. And again, you may want to stack trace the request while it’s hanging. I assume you’ll see it doing a CFHTTP (to kick off the URL defined in the task), but it would be good to confirm.

It all may also give you more info to report in the bug report you say you filed. Hope that helps.

/charlie


Hi Charlie,

Yes it's very strange behaviour.

If the task is running successfully and the cf instance is restarted the task stops executing.

After the instance has restarted the task won't execute on either it's schedule, or a manual execution via the admin -> scheduled tasks page. Once I have "resaved" the task it automatically starts working on it's schedule (without being executed manually a first time) and will execute successfully if I manually run it.

From that point onwards the task continues to execute on it's schedule until the next time the CF instance is restarted. Which I assume is when the neo-cron.xml file is next read into memory.

I just did what you suggested and compared a non working and working neo-cron.xml files and there are some differences!

                              NOT WORKING neo-cron.xml                                                                   WORKING neo-cron.xml

1.           <var name="serverscheduletask#$%^default#$%^TESTTASK">  VS  <var name="SERVERSCHEDULETASK#$%^DEFAULT#$%^TESTTASK">

2.  No clustered node                                                                                     <var name="clustered">

                                                                                                                            <string>false</string>

                                                                                                                       </var>           

3.  <var name="overwrite">                                                                           <var name="overwrite">

        <boolean value="true"/>                                                                               <string>true</string>

    </var>                                                                                                        </var>

4.  <var name="disabled">                                                                            No disabled node

        <boolean value="false"/>

    </var>   

5.  <var name="eventhandlerrp">                                                                 No eventhandlerrp node

        <string/>

    </var>    

I restarted the instance while the task was working and confirmed that the not working changes were made to the cron file. Then saved the task in the cf admin and check the working changes were made to the file. Finally just for good measure I restarted the instance once again and the not working changes were back in the cron file.

The difficult thing is I can't edit the file before starting the instance because it just overwrites what's in there.

Cheers,

Simon

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices