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.
  

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)
  

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!

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.

     

Click here to download:

Monitoring_Tomcat_with_Java_Vi.zip (171 KB)