Skip to main content
I
impalerware
Participating Frequently
July 26, 2023
Answered

Long running scheduled tasks kicking off multiple times

  • July 26, 2023
  • 3 replies
  • 1039 views

Anyone else have an issue with 2021 and long running scheduled task running multiple times?

I've narrowed it down to only occurring using a JDK higher than 11.0.12. 

 

I've been replicating this by scheduling a task to a page with the following content:

 

<cfset sleep(360000)>

<cfmail to="youremail@email.edu" from="testtask@email.edu" subject="test task" type="html">
	<cfdump var='#timeFormat(now(), "HH:mm:ss")#'/>
</cfmail>

 

    Correct answer pichardov

    I have looked into the issue some more, and continue to do so. As far as Java changes go, I have been unable to find any explicit acknowledgement from Oracle or OpenJDK saying something like, “We changed ScheduledThreadPoolExecutor behavior in 11.0.13+". Therefore, the behaviour you observed (ColdFusion scheduled tasks overlapping under JDK 11.0.13 or newer) seems to be an undocumented runtime behavior change rather than a documented API change. The research continues.


    I did a lot of troubleshooting and finally narrowed it down and have a workaround. 

     

    We offload SSL termination to a F5 load balancer. The issue occurs when the scheduled task url hits the F5 first. So going F5 -> IIS -> CF. Still not sure why this only happens with newer Java though.

     

    Since we have a lot of scheduled tasks and I didn't want to update all of them, I hardcoded the IP of the server running CF in its hosts file. So all http requests initiated on the CF server itself will go to itself vs going over to the F5 first.

     

    I did have to create a self signed IIS cert with the same name as the cert on the F5 and trust it into the java keystore. Initially I tried a self signed cert with the hostname of the CF server but for whatever reason, that fails the ssl check even when trusted into the java keystore.

    3 replies

    D
    default8rs3k49y1nan
    Participating Frequently
    September 15, 2025

    I've ran into this issue in the past with long running scheduled tasks and the resolution i've found is wrapping the whole task in a <cfthread> and right after that cfthread open tag <cfouput>any text</cfoutput>. I'm not sure of all the mechanics that make that work, but seems like since scheduler is executing the "task" like it's a page request using a http request,  and that it needs confirmation that the http request resolved and if it doesn't then it trys again to resolve thinking there was a network issue along the way. If you run the task without the cfthread tag by putting the URL in a browser and execute it the page just spins and spins, but if you do the same with the cfthread and the output it resolves the page immediately while the work of the task is still being done behind the scenes. 

    P
    paule12345
    Inspiring
    August 11, 2025

    We observed this behavior on CF2021 when doing bulk email sending, no scheduled task involved.  When we would send, say, a 10,000 email blast via the SMTP service on the local Windows 2019 server,  after X number of minutes the CFM doing the email sending would start running again.   I could see it happening in FusionReactor monitor in real time.   Our solution at the time was running smaller email batches, say, no more than 5000 at a time.   We now use a third party cloud based email sender (SMTP2GO) and don't have the issue anymore because their system processes each SMTP transaction much faster.

    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    August 11, 2025

    @paule12345, your situation sure sounds quite different that what @pichardov had experienced. In fact, your comment here arrived at the very same minute as theirs, offering their workaround.

     

    As for your saying that a cfm page that created mails started running again, if you are thinking there's a connection there, I'll note that the process in cfmail will by default simply put emails into the cf mail spool folder. Cfmail itself doesn't talk to the smtp server.

     

    Instead it's cf itself (a background thread) that wakes up (by default every 15 seconds) to find any such spooled mail to be delivered, and THAT'S what talks to the smtp server. Any failure or hangup in that process would NEVER (itself) cause the cf page doing the cfmails to run again.

     

    It's great to hear you have FR. With that, you should definetky) definitely be able to track down the "repeat offender", finding such details as what ip address kicked it off, what client user agent that was, what web server processed it, what headers came in from the client or web server, and more. 

    /Charlie (troubleshooter, carehart. org)
    P
    pichardov
    Participating Frequently
    August 5, 2025

    We just upgraded to 2023 and this is still happening.

    BKBK
    Community Expert
    BKBKCommunity Expert
    Community Expert
    August 6, 2025

    @pichardov and @w49369461 , please share your:

    • Operating System name and version;
    • ColdFusion version and update level.
    P
    pichardovCorrect answer
    Participating Frequently
    August 11, 2025

    I have looked into the issue some more, and continue to do so. As far as Java changes go, I have been unable to find any explicit acknowledgement from Oracle or OpenJDK saying something like, “We changed ScheduledThreadPoolExecutor behavior in 11.0.13+". Therefore, the behaviour you observed (ColdFusion scheduled tasks overlapping under JDK 11.0.13 or newer) seems to be an undocumented runtime behavior change rather than a documented API change. The research continues.


    I did a lot of troubleshooting and finally narrowed it down and have a workaround. 

     

    We offload SSL termination to a F5 load balancer. The issue occurs when the scheduled task url hits the F5 first. So going F5 -> IIS -> CF. Still not sure why this only happens with newer Java though.

     

    Since we have a lot of scheduled tasks and I didn't want to update all of them, I hardcoded the IP of the server running CF in its hosts file. So all http requests initiated on the CF server itself will go to itself vs going over to the F5 first.

     

    I did have to create a self signed IIS cert with the same name as the cert on the F5 and trust it into the java keystore. Initially I tried a self signed cert with the hostname of the CF server but for whatever reason, that fails the ssl check even when trusted into the java keystore.

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