Explore Posterous

First (?) Production Site on Open BlueDragon for Google App Engine

Yesterday Peter Farrell pointed me to a brochure site he did for a friend. Looks great, it's running Mach-II 1.8 beta, using SES URLs, all great stuff.

Then he told me it was running on Open BlueDragon for Google App Engine (GAE). VERY cool. You can read a bit more about it on Peter's blog. I could be wrong, but I think this may be the first production site running on OpenBD on GAE. (If there are others out there, I'd love some links!)

The interest in running CFML apps on GAE has really been picking up lately, and with good reason. It's a dead simple way to deploy CFML applications to Google's cloud, and unless the site is going to get a huge amount of traffic it's completely free.

Free CFML engine, free hosting, easy deployment right from Eclipse ... there's a lot to love here. No more hunting around for cheap shared hosting accounts that are so restrictive they're barely usable, no more spending money on a VPS if you don't need one (though I highly recommend them!), you just build your app and deploy right to GAE.

Since a lot of people I've been talking with recently aren't all that familiar with GAE, I'd like to point out that it's a bit of a different paradigm than many other cloud computing services. Unlike Amazon EC2, where you're dealing with things at the server level, GAE is application-oriented. So you don't have a server with an operating system on which you install a servlet container and OpenBD, instead you're simply deploying individual applications to Google's Java infrastructure. It's a really nice way to do things since the server-level stuff is all handled for you.

Be aware that there are some restrictions on what you can do on GAE vs. deploying on your own server, but really these are just differences rather than any huge impediments:

• Unless you use the Virtual File System (VFS) that Vince Bonfanti has been building, you can't write to the file system. Note that you can use the VFS on all Java projects on GAE; it isn't specific to OpenBD.
• The limit on the length of a single request is 30 seconds. (Not a problem unless you're generating reports or something.)
• You can't ...
• open a socket or direct connection to another host. You can use GAE's URL Fetch Service to call other hosts on ports 80 and 443.
• spawn new threads
• make system calls
• There are some limitations on request/response sizes, maximum file sizes, etc. but all are quite reasonable.
  

The big difference is that you can't use a traditional RDBMS like MySQL. Instead you use Google's Datastore, which is a "schemaless object datastore." You can read more about Datastore here. So what does this mean for CFML developers? Well, OpenBD for GAE implements persistence for CFCs to Google Datastore, so you can save your CFCs (works for structs as well) to the Datastore by using the GoogleWrite() function, and there are also functions to run queries and read single objects from the Datastore. You can read more about OpenBD's Datastore integration on the OpenBD wiki.

There has also been some work done on making a file-based RDBMS like H2 work with the VFS, and although it works apparently the performance is pretty slow at the moment. When the issues around that get resolved that will be another nice option, since a database could be deployed to GAE right along with your application code.

Personally I'm really excited about the opportunities this offers CFML developers. It could not be simpler to build a site and deploy it on Google App Engine, and the benefits of being on the Google infrastructure are pretty amazing. If your application doesn't get a huge amount of traffic it's completely free, and if your application starts to grow, the underlying infrastructure will scale up automatically as needed. That's one of the many benefits of cloud computing.

If you're interested in getting started with OpenBD on GAE, make sure and join the OpenBD Google Group, check out the GAE section of the wiki, and there are some great blog posts by members of the OpenBD community as well:

• CFML on GAE with OpenBD (Paul Kukiel)
  
• OpenBD GAE and CFCs (Paul Kukiel)
• CFML on GAE with OpenBD (Aaron Lynch)
• Google App Engine's Virtual File System with OpenBD (Aaron Lynch)
• A Better Way to Serve Files from the GAE VFS (Aaron Lynch)
• SES URLs on OpenBD GAE (Peter Farrell)
  

As I said, there's lots to love here, so I encourage you to give it a try.

Server-Side JavaScript with Open BlueDragon

In all the years I've been doing CFML development, CFSCRIPT has always been a neglected afterthought. Due to the limitations I (along with many of you I'm sure) stopped using it. Every time I'd get on a CFSCRIPT kick, I'd find myself frustrated by the limitations, having to break out of script to do things that weren't supported, or taking the time to write my own wrappers for CFML tags.

If only there were a complete, robust, scripting language that web developers already know that could be used instead of CFSCRIPT ...

Using JavaScript on the server side is something we've been discussing on the OpenBD Steering Committee for a while now, and Alan Williamson outlines the progress he's made in making this a reality in a post on his blog. The Mozilla Rhino library serves as the underlying JavaScript engine for this feature, and it will also be compatible with the Google App Engine edition of OpenBD.

I think this will be a great addition to the CFML arsenal not only for the simple reason that we'll be able to write script in our CFML apps using JavaScript 1.7, but this also opens up some really interesting possibilities for integration with existing JavaScript libraries, and will offer anyone who knows JavaScript an easy path into the CFML world.

We'll be releasing a plugin for OpenBD soon and would love to get feedback on the notion of using JavaScript on the server side in your CFML apps. As Alan outlines in his blog post there are still some logistics to work out, but part of the power of open source is getting additions like this in the hands of the community early so we can get your feedback and make sure this feature meets your needs.

Let us know your thoughts on using JavaScript on the server side in your CFML apps!

CFJAVASCRIPT gets a turbo boost

CFML on the Google App Engine with Open BlueDragon | Progressive Overload

Monitoring Tomcat with Java VisualVM

One of the best kept secrets that's bundled with your Java 6 JDK is VisualVM. VisualVM is an absolutely fantastic, free monitoring tool for Java that you may not realize is right under your nose.

In a nutshell, when you fire up VisualVM it provides you with a ton of monitoring tools for everything running on the JVM. By default VisualVM will monitor the VM from which it's launched, so if for example you launch VisualVM from the bin directory of jdk1.6.0_17, then anything using that JVM will show up as a process in VisualVM that can be monitored. Note that in some cases certain processes will not appear in VisualVM, which is the real point of this post; I'll get to that in a moment.

I'm attaching a few screenshots to this post. The first shows what VisualVM looks like when I fired it up just now on my Linux laptop, the second shows a snapshot of the main monitor screen (in this case I'm monitoring Tomcat), and the third shows a snapshot of the thread monitoring screen (note the Open BlueDragon threads!). VisualVM can also take and load snapshots so you really hone in on problems at the VM level quite easily.

One major point I'd like to make is that VisualVM will monitor any Java application running on the JVM. So in the CFML world this means if you have OpenBD, Railo, or ColdFusion running, they can all be monitored quite nicely using VisualVM.

VisualVM can also monitor remote JVMs via JMX (Java Management Extensions), so if you're having trouble on a remote server and want to see what's going on, as long as the JMX ports are open and accessible you can launch VisualVM from your local machine and connect to the remote VM. Note that monitoring is a very lightweight process so VisualVM can be used to monitor production servers with virtual no impact. Visual VM also does profiling, however, which is a much more heavyweight process. It provides a huge amount of useful information, but should be used only when absolutely needed on production servers since it will have a noticeable impact on performance.

Now to the real point of this post. When I launched VisualVM on a Windows 2003 server today I was surprised that Tomcat didn't show up as a process running under the VM. Turns out that if you install Tomcat as a service, even if it's running under the same user account that you used to launch VisualVM, Tomcat won't appear by default in the VisualVM process list.

Luckily it's easy enough to resolve. Simply open the Tomcat Configuration application and add the following in the Java Options box on the Java tab:

-Dcom.sun.management.jmxremote.port=8086
-Dcom.sun.management.jmxremote.ssl=false
 -Dcom.sun.management.jmxremote.authenticate=false

After making this change you do have to restart Tomcat.

This will enable JMX in Tomcat and allow VisualVM to connect to it. You can choose any port you like, and note that if you want to use SSL or authentication you would set those options to true. I haven't personally messed with authentication so I'm not sure what that authenticates against, but know that if you want to have JMX available on a production system that you can secure it this way, or of course through firewall rules.

With JMX enabled in Tomcat you then go into VisualVM, add a new JMX connection, and point it to localhost:8086 (or whatever port you set JMX to run on). That's it--you're now monitoring Tomcat!

VisualVM is a great, free tool that you likely already have on your machine, so you really owe it to yourself to check it out.

Running Tomcat as a Service on 64-Bit Windows

I'm replacing one of our ColdFusion 8 installs with Tomcat 6.0.20 and Open BlueDragon, and this is on a 64-bit Windows 2003 server. Easy enough conceptually, but it turns out running Tomcat as a service on 64-bit Windows has a small trick involved.

A couple of potential solutions are outlined on StackOverflow (and numerous other places), but it still involved a bit of hunting around, so I thought a step-by-step with specific links would be helpful both to others and to myself when I forget how to do this next time. ;-)

1. Install a 64-bit JDK if you haven't already.
2. Download and run the Windows Service Installer of Tomcat.
1. Make sure and point to your 64-bit JVM at the appropriate spot in the install process.
   
2. At the end of the install, uncheck the box to start Tomcat. It won't start anyway at this point since the startup script included in the download is 32-bit.
   
3. Grab the 64-bit versions of tomcat6.exe and tomcat6w.exe from the SVN repository. Even though it says "amd64" in the URL these files work on Intel chips as well.
4. Replace the tomcat6.exe and tomcat6w.exe in Tomcat's bin directory with the new 64-bit versions you downloaded.
5. Start up Tomcat!

That should be all there is to it. The one thing that doesn't work for me is the "Monitor Tomcat" application, but that really isn't a big deal since it doesn't do or tell you anything you can't get from the Services panel. I haven't dug into that at all so if anyone knows why that doesn't run I'd be curious to know.

After this is all installed make sure and go into the Tomcat Configuration app to take advantage of all the RAM you need or want to for your applications.

New QueryRun() + QueryOfQueryRun() functions added to OpenBD

CFML Documentation core to Open BlueDragon

Busy Weekend for Open BlueDragon! New Documentation Site and More New Tags and Functions

More new tags and functions have been added to OpenBD and a brand-new CFML documentation site has been released! You can read more about the very cool new documentation site on the OpenBD blog and Alan Williamson's blog.

The cool thing about the docs site, other than the fact that it exists of course, is that the documentation is being pulled directly from the OpenBD engine, which means the documentation will always be up-to-date.

Because the documentation is being pulled directly from OpenBD, the docs are also specific to the version of OpenBD that you're running. So this isn't only an external site you can use for reference; the code for the documentation site is bundled with the OpenBD nightly builds already so you can run the documentation app on your own instance of OpenBD.

The documentation app also supports comments so you can add tips, etc. to the public site, but you can also leverage this on an instance you may be running internally at your company. This gives you the ability to have a CFML documentation site with notes that are specific to your team.

Here are the new functions and tags that were added in the last couple of days:

• ArrayIndexExists()
• ListIndexExists()
• REMatch()
• REMatchNoCase()
• CFHTMLHead
• CFHTMLHead()
• CFHTMLBody
• CFHTMLBody()

And for those of you who aren't aware, you can follow OpenBD on Twitter (@OpenBlueDragon) to get notifications of the latest goings-on with OpenBD.

FuseNG and therefore Fusebox by default are dead...