In certain instances where you have endlessly running/sleeping ‘monitoring’ threads, there is effectively no way to kill them short of a CF server cycle or via the CF8 server monitor.

I had this issue during development where inside an app scoped component I was creating two ‘monitor’ threads, which were charged with monitoring two separate queues, sleeping every few seconds. Whenever the app scope was reinitialized, two more threads would be created, up to the point where all threads were utilized and the app bombed due to the lingering (and idle) threads left from the previous instantiation.

CFThreads are not application specific, they are bound to the server; furthermore, multiple threads with the same name can be created in different requests. In order to attempt to ‘bind’ a thread to a given application, I recommend prefixing all threads with an application-specific unique string prefix; this will allow you to use the prefix argument of the UDF below and effectively kill only those threads which were spawned from a particular application.

Given all this, I created the following UDF which allows you to kill any cfthread, either by name or by prefix string. Since the cfadmin password is required (the udf interacts with the cfadmin api), if you need to embed this routine into an app, you are suggested to alter the code to allow an encrypted password to be passed in which is subsequently decrypted as required before invoking the admin api login method.