Most of us (and not just CFers) build applications with inline processing, For example, if a user uploads a file we process it in the ACTION page while the user waits. Or if a report needs to be generated we create it while the user waits. Or if we need to send out a batch of e-mail messages … yes, we do it while the user waits.
That’s not a bad thing, some processing must in fact be real-time. If a user fills in a search form and wants to see results, well, those results need to be retrieved while the user waits.
But must all processing happen inline? Suppose you were using the new reporting features in ColdFusion MX 7, and your user filled in a form to select the data to be reported on, and you then generated and displayed the report. Now suppose that you are generating lots of reports, big complex ones. Instead of making the users wait while the reports were generated, you could tell them “working on it, it’ll be in your inbox shortly”. Users will be happier because they’d not be sitting idle waiting, the response would be quicker, and the whole application may run faster too.
That was a simplistic example, but you get the idea. ColdFusion applications have traditionally been processed synchronously, line after line, sequentially. While ColdFusion has always been capable of processing multiple requests at once, we as developers have not had an easy way to fire off our own requests so as to process asynchronously.
But that has changed. ColdFusion MX 7 Enterprise features event gateways, and one included gateway makes performing asynchronous processing very easy.
Here is how it works:

  1. The first thing you need to do is create the ColdFusion code that you’ll be calling. This must be in a ColdFusion Component, and you could very feasibly just move existing code into a CFC method. That CFC method would accept data passed to it (details about the processing to be performed), and would not generate output (which would never really be seen).
  2. Next you’ll define an instance of the asynchronous processing gateway in the ColdFusion Administrator, giving it a unique name, and pointing it to the CFC you just created.
  3. And finally, you’d start the gateway.

With the gateway running you can start submitting requests to it. This is what you’d do:

  1. Create a simple ColdFusion structure containing whatever data you need to pass to your CFC method (the name of the uploaded file to be processed, details about the report to be generated, etc.).
  2. Use the SendGatewayMessage() function to fire the request, you’ll specify 2 parameters, the name of the gateway, and your new structure.

And that’s it! ColdFusion will send the request to the gateway engine which will route it to the correct gateway and your code will execute.
The only gotcha in all of this is how to get information back to users if a problem occurs or if some feedback is required. There are lots of options for this one, including:

  • Write status information to a log file which you’d subsequently check.
  • Use to send a mail message.
  • Use another gateway request to send an IM or SMS alert.

Of course, if you truly do need to fire requests that are guaranteed (to be delivered or to inform you of failure) then you probably will want to use the JMS gateway instead of asynchronous processing. And while this is a little more involved, once configured the process is much the same as described above.
If you want example code to play with, Damon Cooper blogged one a while back.

7 thoughts

  1. Hi, do you know if there is any plan to make this available for standard CF as opposed to enterprise? Its a shame that most of us can’t use it for real.

  2. Hello,
    I have complex reports that if run on larger data sets (more than 2 weeks) have to process 20k+ DB records. To improve user experience I use CF application scope caching. However, memory use is quite steep. Also, we don’t want anything running on our servers for more than 90s – this limits report size.
    I was already suggesting e-mailing reports that would run for more than 1 min. With help of CF7 (which we have on R&D box) this should be easier.

  3. I have to admit the only thing that really excited me about CF7 was the gateway technology.
    It’s as important as the introduction of CFC’s in 6.1 and should have been provided as part of the core functionality of CF 7 and not just available to the enterprise market.
    As an aside are there any limits to the number of gateway events I can spawn? I’m thinking of spawning 2500 events each doing a cfhttp get….
    Is there any formula we should use based on processor speeds etc…

  4. Hey Adam, no guidelines or performance benchmark numbers for the Event Gateway architecture or Gateways published just yet, but they’re definitely on the way.
    We’re working on the CFMX7 Performance Brief and we’ll be sure to get the Event Gateway covered with a full suite of numbers, similar to the testing we did around the new Enterprise CFMAIL performance and scalability results we published in the existing CFMX 6.1 Performance Brief (about 2.1 million emails p/hr on a standard 2-way Intel box if I recall).
    We did spend a good amount if tuned the Event Gateway architecture to within an inch of it’s life (since we envisioned telco-level message volume processing being needed for TV voting apps, large-scale B-to-C deployments with large volume bursts, etc).
    The included Gateways included also went through rigorous tuning independently of the EG architecture, so they’re also very tuned and scalable.
    Anyway, as soon as we can get the Brief out that should help you out.
    I would say that 2,500 simultaneous working threads are a lot of threads, and you’ll likely need to adjust your OS and JVM TCP/IP settings to allow such a large number of simultaneous outbound socket connections (don’t try this one XP! :), but if you wanted to do it, the Event Gateway architecture won’t be in your way, for sure.
    You can some amazing gains and very good performance results with a much smaller number (like 100-200?) concurrent Event Gateway worker request threads, but testing with your app is the best way to figure out how to optimize the user’s experience with this setting (requests queue like on a web server in FIFO fashion until they get one of the EG worker thread simultaneous requests slots.
    Remember, if you were previously doing things in serial (one after the other in an HTTP request, for example), if you can make that work concurrent, you can potentially achieve up to 100% overall performance gain for each of the number of "slices" you can break the work up into (10 even chunks of work can improve user experience and reduce total time vs serial processing by up to 10X, for example…22,000ms down to 220ms for 100 threads, etc).
    (You can look like hero with very little work this way, btw 🙂
    Damon

  5. I have been tryin to work out some of the details for an asynch call I need. I have an external CFHTTP call that returns a data set as an xml packet. This call can take up to 10 seconds to complete, so I want to spwn it off and let it run while the users is navigating some other pages. Problem is, I need to know when the packet gets back and I need to maintain session information across the request so that the user accesses the correct packet of data.
    I’ve successfully set up the gateway and made the call, but I am stuck from there. Any suggestions.

  6. I want to know if its possible to call a function from an asynchronous process? The function am calling exists in the same cfc that is registered on the coldfusion cfml gateway.
    Am building an SMS app that is using coldfusion sms gateway. i need to process a message to bulk recipients so am using the cfml asynchronous gateway. Setting everything up works fine but not sure if the calling another function within the gateway cfc is possible?

  7. I can not find CF Admin > Data & Services > Event Gateways > Gateway Instances option in my local CF admin panel.
    Is there anything that i need to install/configure?

Leave a Reply