Escape Keys - TomdeMan's Blog

Transfer has become almost a necessity for me these days. I recently had to deploy it on a clustered environment, and had to find a way to keep the Transfer cache between nodes in sync.

A centralized caching system like memcache would work, but a lot of refactoring would be required. Not to mention, Transfer's cache is its claim to fame.

I turned to google, and it led me to Sean Corfield's Blog. Where I found a number of good posts on the issue. Even some code that would do most of the dirty work for me. Score!

Almost...It didn't support composite keys. After I went at that, I decided to change the approach from requiring 2 gateways to just 1, and instead of 1 CFC to act as an observer and a gateway, I split them up.

The gateway gets set up in the CF Administrator. A config file is provided, and doesn't require any modification to get you going. Once it's running the JMS acknowledges it as a listener.

The observer gets attached to Transfer. It will trigger a method that sends a message to the JMS. The message carries the Transfer Object Class name and the ID of the Object that was either deleted or updated.

The JMS then brokers the message to all listening nodes.

That's right, there is a catch. It requires an instance of Active MQ JMS Message Broker, on each node That's an opensource Java Messaging Service by the Apache foundation. It's fairly light, taking up around 2MB RAM, and minimal CPU when at work. Not to mention, it's default installation will get you going instantly. The best part is the auto discovery that will detect other brokers on the same network. This frees you from having to maintain the config files for the CF gateway. No need to keep an up-to-date list of IPs for the nodes. You can deploy the gateway as-is to all nodes, and let ActiveMQ do it's thing.

The project is on RIAForge. I've included a sample app along with the code, for a couple reasons. If you are new to all this, then I suggest installing ActiveMQ, and using the sample app to verify everything is setup correctly. The other reason, is to provide sample code to speed up integration.

Comments:

[Add Comment]

Brian says:

Awwwwwwwesome! I am just about to reach the point in redeploying a second web server in our network after we had to go down to one when we moved to Transfer. Your setup and extra documentation will save me from fumbling around. Many thanks!

8/20/08 1:41 PM

Brian says:

Tom,

Got this up and running today on my laptop in preparation for adding it to our cluster. I tried editing some objects in the system and was hoping you could tell me if these log entries indicate it's working or not?

09/04 15:43:56 Information [Thread-15] - TransferSync Cache update IGNORED - {source=brian_x61, className=member.clubmember, key=""937DAAE7-A36A-CDA9-4A57B9EBEE280020""}

I wasn't sure about the "IGNORED" part and figured it could be due to not having any other nodes in my JMS cluster (working locally and all) but wanted to check in. Overall things have been easier than I expected to get working.

One note for you - I didn't need the 4.1.2 activemq jar; I was able to add the activemq-all-5.1.0.jar into my ext directory and it worked fine (well at least it loaded up!)

9/4/08 8:47 PM

TomdeMan says:

@Brian - You got it. That IGNORED message is because it is sending the message to itself. It checks the host machine against the source of the message. If it's coming from itself, then it IGNORES.

Keep me posted on that 5.x JAR.

9/4/08 8:55 PM

dofus kamas says:

good!

12/19/08 8:31 PM

team says:

Thanks for making this available

4/14/09 10:14 PM

Matt says:

It's probably actually clear from the comments on Sean's post, but I just thought I would make a note here as well: While you said "A centralized caching system like memcache would work..." - it actually won't at all because of the serialization process in CF.

5/7/09 4:33 PM

[Add Comment]