FORGEBOX Enterprise 🚀 - Take your ColdFusion (CFML) Development to Modern Times! Learn More...


v2.1.3+0000077 Public

Welcome to CFConcurent

Build Status

CFConcurrent simplifies the use of the Java Concurrency Framework (java tutorial | javadoc) in ColdFusion applications.

CFConcurrent runs on CF11 or higher, and Lucee 4.5.5 or higher.


This is a fork of Marc Esher's original and awesome library found here: All credits for the code and hard work go to Marc. The reason for this fork are:

  • The original repo hasn't been updated in 5 years as of 2018 and we believe Marc is busy on other things other than CFML
  • We wanted to include this library in our Projects and wanted a "modern" way to include it using Forgebox packages
  • We wanted to allow development to continue

We have, of course, reached out to Marc who sent us his blessing via tweet:

Have at it! Good luck and Godspeed.


ColdFusion 9: A user recently discovered that a massive memory leak exists when running this on CF9. Therefore, it is not safe to use this library on Adobe ColdFusion 9. The problem is not in the library but in the interaction between Java executors and ColdFusion. I will attempt to work with Adobe to identify a fix. ColdFusion 10 is unaffected and behaves as expected.

LUCEE 5: CfConcurrent previosly had multiple issues with Lucee 5. We believe these are now resolved as of CfConcurrent 2.1.0 (but please test thoroughly).


Although CFThread is suitable for management-free fire-and-forget concurrency, robust production applications require higher-level abstractions and a greater degree of control. The Java Concurrency Framework (JCF) provides such improvements, and you can take advantage of it using 100% CFML.

You create CFCs that act as "tasks" that return results. You submit those tasks to the JCF for execution. You can then retrieve the execution results immediately when they are available, or you can create a periodic "polling" task which processes the completed results.

In addition, you can easily create cancelable, pausable scheduled tasks directly in your code (think: heartbeats, daemons), freeing you from the 1-minute limitation of ColdFusion's scheduled task implementation.

CFConcurrent's goals are:

  • Simplify Java object and proxy creation
  • Expose common patterns as generic services
  • Expose extensible base components
  • Do not over-reach
  • Limit protectionist tendencies

CFConcurrent is not a "wrapper" library, nor does it hide the Java Concurrency Framework from you.


I started writing concurrent programs in Java in 2004. This library represents what I wish I had in ColdFusion since learning to write concurrent programs.

For CF developers, Concurrency trends thusly: 1) Lob it into CFThread and hope it works. 2) OMG it's hard to do correctly. Let's eat cake. 3) Spend an inordinate amount of time with locks, app and server-scoped based data sharing schemes, and brittle thread-cancelling mechanisms.

I want this library to expose safe, correct concurrency abstractions that enable high-quality concurrent programming in ColdFusion applications.


CFConcurrent ships with running examples and a suite of tests. Docs are in the wiki: To run the examples, open up a web browser.



box install cfconcurrent

Or, download/clone the repository directly.

You may need to create a /cfconcurrent mapping if the installation directory is not directly beneath your webroot.


CFConcurrent owes a great deal to Mark Mandel and JavaLoader. While CFConcurrent uses native Java proxy object creation on CF10, it requires JavaLoader on CF9. This project would not be possible today without JavaLoader.


Doug Lea began util.concurrent in 1998, just a few years after the release of both Java and CF version 1. In 2004, with Java 5, util.concurrent was brought into the JDK as an official package, named java.util.concurrent. Thus, 3 years before ColdFusion received multithreading capabilities via CFThread (in CF8), Java provided a vastly superior approach to concurrency. Unfortunately, CF developers could not take advantage of java.util.concurrent because of the inability to pass ColdFusion Component (CFC) instances to a Java library.

This changed in 2011, when Mark Mandel tweaked the Java proxy object creation facility available in JavaLoader to enable CFC instances to be passed to invocation methods in the Java concurrency framework. With this ability, "concurrency as it should be" is now possible in ColdFusion.

In 2018, Pixl8 have forked this repository in order to help maintain it and better package it for applications that work with ForgeBox / CommandBox.

Support or Contact

Post issues to Pull requests should ideally have accompanying tests (see build/tests).


CFConcurrent is published under the MIT license.

Dependencies (0)

Dev Dependencies (0)



  • Add ability for Lucee 5 or greater to specify a hostname that will be set for any runnable or callable.


  • Always use cgi.server_name when setting host for Lucee runnable and callables (not cgi.host_name)


  • Make cgi.host_name for any runnable/callable Lucee threads match the original thread's hostname


  • Update README
  • Only run our new proxy on Lucee 5
  • No longer need to pass timeout to lucee proxy
  • Refactor to reduce duplication and simplify calling slightly
  • Ensure Lucee callable/runnable proxies are used when getting a 'submittable' proxy
  • Do not catch errors when running java callables - calling code is responsible for that
  • Remove examples from the built version
  • Add java build for safe callable and runnable proxies for Lucee
  • Add Lucee 5 into list of engines to run tests against


  • Simpler and more reliable method to ensure application context is available to threads started within cfconcurrent


  • Remove no longer used files


  • #1 release cloned page context once we are done with it to prevent thread reference issues


  • Bump build number!


  • Add ACF2018 to the test suite :)
  • Add test case for custom naming of threads in the thread pool
  • #4 Clone page context from original thread and copy its state into new threads' page contexts
  • Make test pass more reliably on slower machines
  • #1 change thread name customization from being just a pool name to a pattern used to construct the thread name
  • Add missing thread name var
  • Fix the cfinclude tag to be engine compatiable and look to the right helper cfm :)
  • Separate out Lucee specific syntax into a separate cfm only included when running on Lucee
  • Ignore generated log directories from Adobe CF engine
  • Remove JavaLoader. As CFCOncurrent works with ACF10+ and not 9 - JL not required.
  • Add a custom thread factory to allow us to customize thread names + create global work arounds for engine issues - i.e. stop requests timeouts from kill thread pool threads
  • Ensure application.applicationName is not used when not available


  • Initial import from Mark Mandel's project

$ box install cfconcurrent

No collaborators yet.
  • {{ getFullDate("Nov 08 2019 04:11 AM GMT") }}
  • {{ getFullDate("Nov 08 2019 04:11 AM GMT") }}
  • 1,998
  • 3,230
  • 3,549