I had promised a summary page a while ago concerning my two articles on ColdFusion's Asynch Gateways. In case you missed it, here are the older articles:
Using ColdFusion's Asynchronous Gateway
Using ColdFusion's Asynchronous Gateway - 2
There were a few things I didn't get to that I'm going to cover in this post. First off - since my last article, Damon Cooper has updated his cfthread/cfjoin proof of concept. Be sure to check it out as it is a very simple, yet currently unsupported, way of doing asynch CFML.
Next - for another way of working with Asynch CFML, check out Sean Corfield's Concurrency library. You can even use this in Model-Glue: Unity which is pretty darn cool.
Lastly, I wanted to talk a bit more about the data structure you send to the gateway with the sendGatewayMessage function. I alluded to the fact that there were some "special" keys that you should not use as they have special meaning to the Asynch Gateway. They are:
cfcpath
method
originatorID
timeout
I'll start from the bottom. If you pass a timeout key in the data structure, it will tell ColdFusion how long your asynch code should be allowed to run. If not used, it defaults to the Timeout Request value in the ColdFusion admin. You would use this if you think your process may need more time.
As you can imagine, originatorID lets you give a custom value for the originatorID. This is passed to your CFC and defaults to CFMLGateway. This could be useful for logging purposes, or could even change what your code does.
The method value changes what method the gateway will call on your CFC. By default the method is onIncomingMessage.
Ok - so what about CFCPath? Well, if you remember from the first post, I talked about how you needed to create a Gateway Instance and point it to a CFC. One question you may have is - what if my application needs to do multiple things in an asynchronous manner? Well, you could use multiple gateways, but that may be overkill if you have quite a few different things you want to run asynchronously. You could also use different methods. That works - but then you may be mixing code for different business rules all in one CFC.
The cfcpath value lets you simply override the CFC that gets called. This way you could make one instance and have it work with multiple CFCs. One thing to note - the value must be the full path to the CFC, not the relative "dot" path we are used to.
Archived Comments
Ever seen a null gateway error message?
Error invoking CFC for gateway InterFax: null
The CFC works fine by itself.
Nope. Maybe look into the logs a bit?
the only other thing it says in the exception log is:
coldfusion.runtime.AbortException
i'd love to get this gateway thing working. it's an interesting concept.
I've seen that logged when cfabort is run. Are you maybe cfaborting somewherE?
no cfaborting anywhere in the code.
but i am doing a cfabort in my application.cfm. when i took it out, it worked.
Ray, I just want to say thank you for putting this series out there. It's really helped me out. The solution that I used with event gateways has my mind free of worry. Because it solved my problem so well that now I can think about more important things. It was a requestTimeout problem that I was running out of ideas on how to fix, and I was seeing it everyday. That means everyday I was worrying about how many timeout error message emails I was going to see in my inbox today. Also, I took a look at the Concurrency library and found it to be too much to learn for what I was looking for. I just wanted to send the gateway a message using the CFC I was already using. So I just added a method called onIncomingMessage to my CFC and boom (tough acting tinactin) I had my whole process running on the gateway. Ahh, no more worrying about timeouts.. I feel like I'm living it up. Just sitting back and watching the event gateway thread-out my process. Thank you to Ray and CF Event Gateways.
This comment is like 3 years late, but I'd like to know which Ray method would recommend using in CF8 to fire off a routine to generate 1000's of emails so the user doesn't have to hang around waiting. Either (1) an asynchronous event gateway or (2) cfthread without waiting for the thread to finish and rejoin?
In other words, does cfthread really supercede the achynchronous event gateway? Thanks.
I honestly had not thought of this. I'd probably just use cfthread and don't JOIN on it.
I know for CFBloggers.org I used that method.