919 - 926 - 9847

ColdFusion Builder Trial: connecting up RDS

My it's been awhile hasn't it?  New job, old job, and other jobs between have been keeping me more busy than I can even relate.

Just for kicks I've decided to give the CFBuilder trial a whirl.  It's being evaluated by the office, and we were having some issues connecting it up to RDS on our local machines.  This lead to the some exploring to find out where the problem lies.

First I went out and grabbed CF Builder 2.  http://www.adobe.com/products/coldfusion-builder.html.  After it got done installing I tried setting up an RDS interface to my local CF 9 install.  And, whoops, hit upon the same error my co-worker saw.  It's fairly unhelpful, mostly just a null java pointer exception.  It lead me to this page on the Adobe forums http://forums.adobe.com/message/4234561, but offered no real resolution.

It dawned on me that RDS was likely not enabled during the installation of CF 9 on my current laptop.  I did the following to address the issue with RDS not connecting (note, some steps may not be necessary, such as adding a new RDS user, but it didn't work for me without one).

  • Open your ColdFusion administrator interface and under the security left hand navigation set both administrator and RDS to use Separate user name and password authentication (allows multiple users) .
  • Create a new RDS user and give them every authority under the sun (eh, it's local).
  • Open up the ColdFusion instance web.xml, and this will vary depending on how you installed ColdFusion.  Mine was found in C:\ColdFusion9\wwwroot\WEB-INF.  The multi-server install will be in a path similar to <jrun-install>\servers\<instance>\cfusion-ear\cfusion-war\WEB-INF.
  • Do a search on RDS.  There should be two separate <servlet> mappings which need to be uncommented.  Uncomment each block.
  • Restart ColdFusion.
  • In CF Builder add a new server for RDS (or edit an existing one).  It was a tab in the bottom pane of the program for my installation.
    • Server Name:  This can be any value, it's just used the purpose of display
    • Application Server: I'll presume you're using JRun
    • Host Name: localhost
    • WebServer Port: 8500 for standard install, consult jrun.xml if you're using multi-server
    • RDS User Name: Name used in the previous step
    • RDS Password: Again, from a previous step
    • Click Next
    • Server Home: Mine was C:\ColdFusion9, not sure where this is on multi-server
    • Document Root: It defaults to wwwroot for the ColdFusion9 folder, and I don't see a reason to change it.
    • Click Finish

After the above, both my co-worker and I were able to successfully connect to our RDS services.

You learn something new every day!

I had to complete a disaster recovery project this week. We do this annually for one of our clients (yay for preparedness!) for one of their ColdFusion sites. I've got a run book and all that and was prepared to reinstall ColdFusion and copy in their EAR to redeploy the application. Until I had a conversation with a coworker: Him> Did they restore your data yet? Me> Yep, I'm just getting ready to reinstall ColdFusion and- Him> Re-install? Isn't everything already there? Me> Well, yeah, but. Wait... huh. I bet I could just run the jrunsvc command, and..

So it turns out, if you don't need search, .NET, LiveCycle or ODBC services, you can just restore ColdFusion from a a backup to your file system. All you really need (minus those other pieces) is to run the jrunsvc command to install a new ColdFusion service in the the services console and to run the wsconfig.jar to connect IIS to JRun (or, if you restore the website from a file, all of that is already there). My runbook went from something like 30 steps down to about 4. Color me happy. And when you think about it, it makes sense. Since it's all built atop Java (minus the other services) there's no reason to go through the installer. You can probably install those other components but I don't really need them, so I don't care to find out how at present. But still, this is a handy little tid bit.

Google brought down my house of cards

For almost three years now we've been running ColdFusion (well, really JRun) session based replication and failover on all of our hosted ColdFusion environs. Things were great! And then, we let google in the door to index our content. Things went from "great", to "why is this always down??". I spent far too much time looking at JVM settings, JRun settings, etc., but never really came up with a concrete answer as to what was happening. Ultimately, we'd see a deluge of errors about the failure of session replication in the log files and a complete breaking of failover and sometimes even the JRun -> IIS connector.

Whilst searching for the session replication errors, I came across Sean Corfields postings across various blogs that replication just does not scale well, and that it remains a broken feature. Up until a few months ago, I'd argue this to be untrue. However, it appears that replication works... if you can manage to keep the amount of crap you throw into shared memory scopes down to a minimum.

It's been 4 days since I've disabled session replication, and my servers have remained standing for an equal amount of time. We've been getting indexed by google (and others), and things are sailing along with nary a blip. Next stop, creating a guide for users that want/need session based failover that can be accomplished in code. Otherwise known as, "Help me Sean Corfield, you're my only hope!" ;).

PNG not showing using Built-in JRun webserver

My friend Michael blogged about an issue he was having with viewing PNG files when using the built-in JRun webserver. Just in case this should ever happen to you, here's the link.

It appears I didn't get the link right. It's fixed now.