Gateways; you've heard about them. You've read the hype. You've probably created one or two. You've seen applications do wonderful things with them. There have been articles written about them.

 Don't be fooled. Not everything is always the way it seems. There's a dark side to the gateway system. A side where things don't go as expected.

I think the gateway system is like an exotic sports car with a child at the wheel. It is full of power, has extensive form and tons of function. But it seems like someone with no knowledge or understanding is at the controls.

Gateways can be very powerful; so powerful that they can flood a server from the inside creating what could be called a sort of denial of service attack from the inside. It's obviously not an attack but the effect is about the same. The server becomes overloaded handling gateway requests and can run out of resources to handle normal traffic.

This usually occurs when you have multiple gateways and they all start firing at the same time. It can even be caused by an asynchronous gateway that's repeatedly fired and doesn't terminate. You can even have a condition where you have hung gateways that aren't terminating.

Due to the nature of gateways there's no easy way to recover from this. Your only recourse is to restart the ColdFusion service. Although restarting the service will fix the problem, you'll have lost whatever was running at restart. You could end up with corrupt data or a whole slew of other issues.

My goal is to help you take control of the gateway system. I'm going to show you how to put a "Gatekeeper" on top of gateways; a method in which all gateway requests are queued. Once queued they can be controlled better and prevent the gateways from overrunning the server. But creating a "Gatekeeper" won't save you from crashes.

The amount of work is minimal. All you need to do is modify your existing gateway cfcs. Just a couple of minor tweaks to your current cfcs and you'll be off and running.
The queue system has two parts: the "Gatekeeper" and a "Dispatcher." They each have their own job but work together to create the queue. Once you actually have this you can create a monitor to keep tabs on everything. This article won't cover this part but the online code contains code for a monitor.
The Gatekeeper takes incoming gateway requests and converts them to server vars that will be used by the Dispatcher and the Monitor. The Dispatcher takes the server vars created by the Gatekeeper and creates asynchronous calls to the appropriate cfcs. The Monitor does just what its name suggests. It keeps tabs on the jobs running and will stop the processing of new requests if things go badly.

The final part is the original gateway cfcs themselves. They need a slight alteration that will let them work with the queue. It starts with the alterations to the current gateway cfcs. The code in Listing 1 demonstrates the code changes needed. Copy the onAdd function and create a new function called GKonAdd. Then the onAdd event is altered to send the event to the Gatekeeper.

Listing 2 is the Gatekeeper itself. All it does is take the event passed to it and stores it in a server variable called "server.cfcevents." You can use either the application or the server scope for this. However, if you use application you have to deal with application timeouts.

The Gatekeeper creates a structure for each gateway that's using it. The structure name is based on the gateway id from the CF administrator. After adding the structure it then fires the Dispatcher asynchronous gateway. You'll have to create this gateway in the CF administrator.

The Dispatcher has a case for each gateway event as well as how many concurrent requests can be running. The Dispatcher is designed to run forever once it starts. It contains code to make it pause as well as detect if it's already running when it starts. If a Dispatcher instance is already running the new instance will shut down. The code for the Dispatcher is very involved and lengthy so it's not in this article but it is available online.
Once you have the Dispatcher set up for your gateways you're ready to go. If you need to you can also set up special conditions in the Dispatcher that will let a request be run immediately and bypass the queue.

Unfortunately I haven't figured out how to do crash recovery. You could write events to a text file instead of the application or server scope. However, then you're limited as to what data you can store. This also adds excess overhead.

And there you have it. You're now back in control of your system. You no longer have to worry about your gateways taking over your system. Hopefully in the future functionality like this will be core to CF and a workaround like this won't be necessary. But until then we have to do what we can to remain in control of our systems.